[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
  
All checks completed, Travis and spotless are happy, could you accept?


---
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: Feature branch cleanup

[Anthony Baker]

> On Mar 6, 2017, at 7:46 AM, Anthony Baker  wrote:
> 
> Last chance to comment:  I’ll be cleaning up these branches over the next few 
> days.
> 
> Anthony

I’ve listed the remaining branches below.  If you know that a branch is no 
longer relevant (e.g. spotlessPlugin) feel free to remove it with

git push origin --delete 

You can automatically cleanup the remote branch (if it exists) when you merge 
the feature branch:

git flow feature finish -rF GEODE-


  origin/GEODE-2153
  origin/GEODE-2290
  origin/GEODE-4160-mockito
  origin/HEAD -> origin/master
  origin/awaitility
  origin/cluster-config
  origin/cluster-config-cleanup
  origin/develop
  origin/feature/GEM-1032
  origin/feature/GEODE-10
  origin/feature/GEODE-11
  origin/feature/GEODE-1153
  origin/feature/GEODE-1209
  origin/feature/GEODE-1269
  origin/feature/GEODE-1466
  origin/feature/GEODE-16
  origin/feature/GEODE-178
  origin/feature/GEODE-1793
  origin/feature/GEODE-1883
  origin/feature/GEODE-1895
  origin/feature/GEODE-1912
  origin/feature/GEODE-1968
  origin/feature/GEODE-1987
  origin/feature/GEODE-2001
  origin/feature/GEODE-2160
  origin/feature/GEODE-2201
  origin/feature/GEODE-2231
  origin/feature/GEODE-2238
  origin/feature/GEODE-2267
  origin/feature/GEODE-2367
  origin/feature/GEODE-2398
  origin/feature/GEODE-2402
  origin/feature/GEODE-2444
  origin/feature/GEODE-2449
  origin/feature/GEODE-2488
  origin/feature/GEODE-2497
  origin/feature/GEODE-2541
  origin/feature/GEODE-2558
  origin/feature/GEODE-2589
  origin/feature/GEODE-259
  origin/feature/GEODE-2616
  origin/feature/GEODE-288
  origin/feature/GEODE-308
  origin/feature/GEODE-64
  origin/feature/GEODE-78
  origin/feature/GEODE-79
  origin/feature/GEODE-80
  origin/feature/e2e-testing
  origin/feature/spotlessPlugin
  origin/feature/wan_single_hop_wip
  origin/gh-wiki
  origin/master
  origin/native-client-software-grant
  origin/next-gen-native-client-software-grant
  origin/sga2
  origin/staging/docs-grant1
  origin/wan_cq_donation

Anthony

Errored: apache/geode-native#152 (develop - aff706b)

[Travis CI]

Build Update for apache/geode-native
-

Build: #152
Status: Errored

Duration: 14 seconds
Commit: aff706b (develop)
Author: Danilo Chang
Message: GEODE-2509: Build failed at openSUSE LEAP 42.2

This issue is when you use configure but does not specify lib
folder name on openSUSE, the default is "lib64" at 64bit
environment (not lib). Use --libdir option to specify the path.

View the changeset: 
https://github.com/apache/geode-native/compare/7da9d90bdd28...aff706be228c

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

--

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

Re: Feature branch cleanup

[Jinmei Liao]

I believe there must be some permission regarding "delete branch" that I
don't have. I did the following and the command returns saying the branch
is deleted, but the branch is STILL there.
$ git push origin --delete cluster-config
To https://git-wip-us.apache.org/repos/asf/geode.git
 - [deleted] cluster-config


Please also delete the following branches as well:
  origin/GEODE-2153
  origin/cluster-config
  origin/cluster-config-cleanup

Thanks!

On Wed, Mar 8, 2017 at 7:20 AM, Anthony Baker  wrote:

>
> > On Mar 6, 2017, at 7:46 AM, Anthony Baker  wrote:
> >
> > Last chance to comment:  I’ll be cleaning up these branches over the
> next few days.
> >
> > Anthony
>
> I’ve listed the remaining branches below.  If you know that a branch is no
> longer relevant (e.g. spotlessPlugin) feel free to remove it with
>
> git push origin --delete 
>
> You can automatically cleanup the remote branch (if it exists) when you
> merge the feature branch:
>
> git flow feature finish -rF GEODE-
>
>
>   origin/GEODE-2153
>   origin/GEODE-2290
>   origin/GEODE-4160-mockito
>   origin/HEAD -> origin/master
>   origin/awaitility
>   origin/cluster-config
>   origin/cluster-config-cleanup
>   origin/develop
>   origin/feature/GEM-1032
>   origin/feature/GEODE-10
>   origin/feature/GEODE-11
>   origin/feature/GEODE-1153
>   origin/feature/GEODE-1209
>   origin/feature/GEODE-1269
>   origin/feature/GEODE-1466
>   origin/feature/GEODE-16
>   origin/feature/GEODE-178
>   origin/feature/GEODE-1793
>   origin/feature/GEODE-1883
>   origin/feature/GEODE-1895
>   origin/feature/GEODE-1912
>   origin/feature/GEODE-1968
>   origin/feature/GEODE-1987
>   origin/feature/GEODE-2001
>   origin/feature/GEODE-2160
>   origin/feature/GEODE-2201
>   origin/feature/GEODE-2231
>   origin/feature/GEODE-2238
>   origin/feature/GEODE-2267
>   origin/feature/GEODE-2367
>   origin/feature/GEODE-2398
>   origin/feature/GEODE-2402
>   origin/feature/GEODE-2444
>   origin/feature/GEODE-2449
>   origin/feature/GEODE-2488
>   origin/feature/GEODE-2497
>   origin/feature/GEODE-2541
>   origin/feature/GEODE-2558
>   origin/feature/GEODE-2589
>   origin/feature/GEODE-259
>   origin/feature/GEODE-2616
>   origin/feature/GEODE-288
>   origin/feature/GEODE-308
>   origin/feature/GEODE-64
>   origin/feature/GEODE-78
>   origin/feature/GEODE-79
>   origin/feature/GEODE-80
>   origin/feature/e2e-testing
>   origin/feature/spotlessPlugin
>   origin/feature/wan_single_hop_wip
>   origin/gh-wiki
>   origin/master
>   origin/native-client-software-grant
>   origin/next-gen-native-client-software-grant
>   origin/sga2
>   origin/staging/docs-grant1
>   origin/wan_cq_donation
>
> Anthony
>
>


-- 
Cheers

Jinmei

[jira] [Resolved] (GEODE-2579) ClassCastException cannot cast CompiledIn to CompiledJunction when querying with a junction containing an in clause

[Jason Huynh (JIRA)]

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

Jason Huynh resolved GEODE-2579.

   Resolution: Fixed
Fix Version/s: 1.2.0

> ClassCastException cannot cast CompiledIn to CompiledJunction when querying 
> with a junction containing an in clause
> ---
>
> Key: GEODE-2579
> URL: https://issues.apache.org/jira/browse/GEODE-2579
> Project: Geode
>  Issue Type: Bug
>  Components: querying
>Affects Versions: 1.0.0-incubating
>Reporter: Jason Huynh
>Assignee: Jason Huynh
> Fix For: 1.2.0
>
>
> A query that causes a junction to form with a compiled in clause may throw 
> the following exception: 
> java.lang.ClassCastException: 
> org.apache.geode.cache.query.internal.CompiledIn cannot be cast to 
> org.apache.geode.cache.query.internal.CompiledJunction
>   at 
> org.apache.geode.cache.query.internal.AbstractGroupOrRangeJunction.(AbstractGroupOrRangeJunction.java:78)
>   at 
> org.apache.geode.cache.query.internal.GroupJunction.(GroupJunction.java:55)
>   at 
> org.apache.geode.cache.query.internal.GroupJunction.recreateFromOld(GroupJunction.java:61)
>   at 
> org.apache.geode.cache.query.internal.CompositeGroupJunction.evaluateAndJunction(CompositeGroupJunction.java:348)
>   at 
> org.apache.geode.cache.query.internal.CompositeGroupJunction.filterEvaluate(CompositeGroupJunction.java:93)
>   at 
> org.apache.geode.cache.query.internal.CompiledJunction.filterEvaluate(CompiledJunction.java:187)
>   at 
> org.apache.geode.cache.query.internal.CompiledSelect.evaluate(CompiledSelect.java:545)
>   at 
> org.apache.geode.cache.query.internal.CompiledSelect.evaluate(CompiledSelect.java:57)
>   at 
> org.apache.geode.cache.query.internal.DefaultQuery.executeUsingContext(DefaultQuery.java:579)
>   at 
> org.apache.geode.cache.query.internal.DefaultQuery.execute(DefaultQuery.java:391)
>   at 
> org.apache.geode.cache.query.internal.DefaultQuery.execute(DefaultQuery.java:323)
>   at 
> org.apache.geode.cache.query.QueryJUnitTest.creatingACompiledJunctionWithACompiledInClauseDoesNotThrowException(QueryJUnitTest.java:334)
>   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:483)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
>   at 
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:117)
>   at 
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:42)
>   at 
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:262)
>   at 
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:84)
>   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:483)
>   at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
> A sample query would be :
> select 
> regionB.userId,regionA.professionCode,regionB.postCode,regionB.userName 

Re: Review Request 57206: let LuceneResultStruct to be Serializable, then customer does not have to defined their Serializable class to hold result

[Dan Smith]

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



Did this work? I think you need to register the DSFID. See 
LuceneServiceImpl.registerDataSerializables.

- Dan Smith


On March 8, 2017, 5:49 a.m., xiaojian zhou wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/57206/
> ---
> 
> (Updated March 8, 2017, 5:49 a.m.)
> 
> 
> Review request for geode, Barry Oglesby and Dan Smith.
> 
> 
> Bugs: GEODE-2617
> https://issues.apache.org/jira/browse/GEODE-2617
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> If customer call a lucene query in a function, they need to define their own 
> Serializable class to collect results. This has been complained by field 
> engineer. 
> 
> It will not hurt to let LuceneResultStruct to extend Serializable
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/internal/DataSerializableFixedID.java
>  63a95a5 
>   
> geode-lucene/src/main/java/org/apache/geode/cache/lucene/LuceneResultStruct.java
>  5d2184e 
>   
> geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/LuceneResultStructImpl.java
>  6c31025 
> 
> 
> Diff: https://reviews.apache.org/r/57206/diff/2/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> xiaojian zhou
> 
>

[GitHub] geode pull request #404: Geode 2469

[ggreen]

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

https://github.com/apache/geode/pull/404#discussion_r104974260
  
--- Diff: 
geode-core/src/main/java/org/apache/geode/redis/internal/executor/hash/HashInterpreter.java
 ---
@@ -0,0 +1,126 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more 
contributor license
+ * agreements. See the NOTICE file distributed with this work for 
additional information regarding
+ * copyright ownership. The ASF licenses this file to You under the Apache 
License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the 
License. You may obtain a
+ * copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software 
distributed under the License
+ * is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF 
ANY KIND, either express
+ * or implied. See the License for the specific language governing 
permissions and limitations under
+ * the License.
+ */
+package org.apache.geode.redis.internal.executor.hash;
+
+import java.util.Map;
+
+import org.apache.geode.cache.Region;
+import org.apache.geode.redis.GeodeRedisServer;
+import org.apache.geode.redis.internal.ByteArrayWrapper;
+import org.apache.geode.redis.internal.Coder;
+import org.apache.geode.redis.internal.ExecutionHandlerContext;
+import org.apache.geode.redis.internal.RedisDataType;
+
+/**
+ * Utility class for interpreting and processing Redis Hash data structure
+ * 
+ *
+ */
+public class HashInterpreter {
+
+  /**
+   * 
+   * The region:key separator.
+   * 
+   *  REGION_KEY_SEPERATOR = ":"
+   * 
+   * See Hash section of https://redis.io/topics/data-types";>https://redis.io/topics/data-types#Hashes
+   * 
+   */
+  public static final String REGION_KEY_SEPERATOR = ":";
+
+  /**
+   * The default hash region name REGION_HASH_REGION = 
Coder.stringToByteArrayWrapper("ReDiS_HASH")
+   */
+  public static final ByteArrayWrapper REGION_HASH_REGION =
+  Coder.stringToByteArrayWrapper(GeodeRedisServer.HASH_REGION);
+
+  /**
+   * Return the region presenting the hash
+   * 
+   * @param key the raw Redis command key that may contain the region:key 
formation
+   * @param context the exception handler context
+   * @return the region were the command's data will be processed
+   */
+  @SuppressWarnings("unchecked")
+  public static Region> getRegion(
--- End diff --

@galen-pivotal: I really like the idea of a single region. The less the 
number of regions, then the less overhead, but for now I just limited the 
change to using the Redis_Hash region. This same region will be used for HASH 
data types of objects and non-objects.
This pull request was originally based on an attempt to get some Spring 
Data Redis example code to work with the GemFire Redis adaptor.

Also, @wwilliams-pivotal  and @hiteshk25: I believe I incorporated your 
observations.
I also tried to improve the integration tests for the hash related commands.

Please review my latest commit, and let me know if any additional changes 
are needed as a pre-requisite for accepting this pull request.


---
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] [Assigned] (GEODE-2614) Build generates javadoc warnings

[Jinmei Liao (JIRA)]

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

Jinmei Liao reassigned GEODE-2614:
--

Assignee: Jinmei Liao

> Build generates javadoc warnings
> 
>
> Key: GEODE-2614
> URL: https://issues.apache.org/jira/browse/GEODE-2614
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh, jmx
>Reporter: Kirk Lund
>Assignee: Jinmei Liao
>  Labels: javadocs
>
> {noformat}
> /Users/klund/dev/geode/geode-core/src/main/java/org/apache/geode/management/internal/cli/util/LogExporter.java:56:
>  warning - @param argument "logFilter:" is not a parameter name.
> /Users/klund/dev/geode/geode-core/src/main/java/org/apache/geode/management/internal/cli/util/LogExporter.java:56:
>  warning - @param argument "baseLogFile:" is not a parameter name.
> /Users/klund/dev/geode/geode-core/src/main/java/org/apache/geode/management/internal/cli/util/LogExporter.java:56:
>  warning - @param argument "baseStatsFile:" is not a parameter name.
> /Users/klund/dev/geode/geode-core/src/main/java/org/apache/geode/management/internal/cli/CliAroundInterceptor.java:45:
>  warning - @param argument "tempFile:" is not a parameter name.
> {noformat}



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

[jira] [Resolved] (GEODE-2614) Build generates javadoc warnings

[Jinmei Liao (JIRA)]

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

Jinmei Liao resolved GEODE-2614.

   Resolution: Fixed
Fix Version/s: 1.2.0

> Build generates javadoc warnings
> 
>
> Key: GEODE-2614
> URL: https://issues.apache.org/jira/browse/GEODE-2614
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh, jmx
>Reporter: Kirk Lund
>Assignee: Jinmei Liao
>  Labels: javadocs
> Fix For: 1.2.0
>
>
> {noformat}
> /Users/klund/dev/geode/geode-core/src/main/java/org/apache/geode/management/internal/cli/util/LogExporter.java:56:
>  warning - @param argument "logFilter:" is not a parameter name.
> /Users/klund/dev/geode/geode-core/src/main/java/org/apache/geode/management/internal/cli/util/LogExporter.java:56:
>  warning - @param argument "baseLogFile:" is not a parameter name.
> /Users/klund/dev/geode/geode-core/src/main/java/org/apache/geode/management/internal/cli/util/LogExporter.java:56:
>  warning - @param argument "baseStatsFile:" is not a parameter name.
> /Users/klund/dev/geode/geode-core/src/main/java/org/apache/geode/management/internal/cli/CliAroundInterceptor.java:45:
>  warning - @param argument "tempFile:" is not a parameter name.
> {noformat}



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

[jira] [Commented] (GEODE-2614) Build generates javadoc warnings

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2614:


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

GEODE-2614: fix javadoc warnings


> Build generates javadoc warnings
> 
>
> Key: GEODE-2614
> URL: https://issues.apache.org/jira/browse/GEODE-2614
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh, jmx
>Reporter: Kirk Lund
>Assignee: Jinmei Liao
>  Labels: javadocs
> Fix For: 1.2.0
>
>
> {noformat}
> /Users/klund/dev/geode/geode-core/src/main/java/org/apache/geode/management/internal/cli/util/LogExporter.java:56:
>  warning - @param argument "logFilter:" is not a parameter name.
> /Users/klund/dev/geode/geode-core/src/main/java/org/apache/geode/management/internal/cli/util/LogExporter.java:56:
>  warning - @param argument "baseLogFile:" is not a parameter name.
> /Users/klund/dev/geode/geode-core/src/main/java/org/apache/geode/management/internal/cli/util/LogExporter.java:56:
>  warning - @param argument "baseStatsFile:" is not a parameter name.
> /Users/klund/dev/geode/geode-core/src/main/java/org/apache/geode/management/internal/cli/CliAroundInterceptor.java:45:
>  warning - @param argument "tempFile:" is not a parameter name.
> {noformat}



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

[jira] [Assigned] (GEODE-2420) Warn a user if they try to export too much data

[Kirk Lund (JIRA)]

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

Kirk Lund reassigned GEODE-2420:


Assignee: Kirk Lund

> Warn a user if they try to export too much data
> ---
>
> Key: GEODE-2420
> URL: https://issues.apache.org/jira/browse/GEODE-2420
> Project: Geode
>  Issue Type: Sub-task
>  Components: configuration, docs, gfsh
>Reporter: Jared Stewart
>Assignee: Kirk Lund
>
> We should warn a user and prompt for confirmation before trying to perform an 
> `export logs` operation that would result in a file over some threshold.  
> (Logs and stats have the potential to be very large.)



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

[jira] [Commented] (GEODE-2614) Build generates javadoc warnings

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2614:


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

GEODE-2614: fix javadoc warnings - spotless


> Build generates javadoc warnings
> 
>
> Key: GEODE-2614
> URL: https://issues.apache.org/jira/browse/GEODE-2614
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh, jmx
>Reporter: Kirk Lund
>Assignee: Jinmei Liao
>  Labels: javadocs
> Fix For: 1.2.0
>
>
> {noformat}
> /Users/klund/dev/geode/geode-core/src/main/java/org/apache/geode/management/internal/cli/util/LogExporter.java:56:
>  warning - @param argument "logFilter:" is not a parameter name.
> /Users/klund/dev/geode/geode-core/src/main/java/org/apache/geode/management/internal/cli/util/LogExporter.java:56:
>  warning - @param argument "baseLogFile:" is not a parameter name.
> /Users/klund/dev/geode/geode-core/src/main/java/org/apache/geode/management/internal/cli/util/LogExporter.java:56:
>  warning - @param argument "baseStatsFile:" is not a parameter name.
> /Users/klund/dev/geode/geode-core/src/main/java/org/apache/geode/management/internal/cli/CliAroundInterceptor.java:45:
>  warning - @param argument "tempFile:" is not a parameter name.
> {noformat}



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

Re: Storing object in deserialized form in geode cache

[Michael Stolz]

The rule is, if you deserialize the object in the server side, Geode keeps
the deserialized version of it around.

As for updating in place...this is the position that the docs for
Commercial GemFire take on that subject:

"If you do not have the cache copy-on-read attribute set to true, do not
change the objects returned from the Java entry access methods. Instead,
create a copy of the object, then modify the copy and pass it to the Java
put method. Modifying a value in place bypasses the entire distribution
framework provided by GemFire, including cache listeners and expiration
activities, and can produce undesired results."

Of course if that's exactly the behavior you WANT, then set
copy-on-read=false.



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

On Wed, Mar 8, 2017 at 1:37 AM, Deepak Dixit 
wrote:

> Hello Geode Team,
>
> I am working on a use case where I want to store the java object. I want to
> avoid the serialization and deserialization while reading on server
> (function execution).
> Also while updating I would like to update in-place rather than to create
> copy of object, modify and store it again in underlying map.
>
> Based on my current understanding, every object is wrapped in
> "VMCachedDeserializable" and serialized / deserialized while doing get/put.
>
> Kindly advice the way with which I can store object in deserialized form in
> cache and do in place modifications.
>
> Thanks,
> Deepak
>

[jira] [Created] (GEODE-2632) Integrated Security performance improvements

[Jinmei Liao (JIRA)]

Jinmei Liao created GEODE-2632:
--

 Summary: Integrated Security performance improvements
 Key: GEODE-2632
 URL: https://issues.apache.org/jira/browse/GEODE-2632
 Project: Geode
  Issue Type: Improvement
Reporter: Jinmei Liao


There is a security check in Put65.cmdExecute() that, if removed, improved the 
performance.
The expense of this security call needs to be reduced in order to get the 
performance back.



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

[jira] [Commented] (GEODE-2579) ClassCastException cannot cast CompiledIn to CompiledJunction when querying with a junction containing an in clause

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2579:


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

GEODE-2579: ClassCastException cannot cast CompiledIn to CompiledJunction

*  AbstractGroupOrRangeJunction does not incorrectly cast when creating 
junction with in clause
*  In clause will be handled like a compiled comparison


> ClassCastException cannot cast CompiledIn to CompiledJunction when querying 
> with a junction containing an in clause
> ---
>
> Key: GEODE-2579
> URL: https://issues.apache.org/jira/browse/GEODE-2579
> Project: Geode
>  Issue Type: Bug
>  Components: querying
>Affects Versions: 1.0.0-incubating
>Reporter: Jason Huynh
>Assignee: Jason Huynh
> Fix For: 1.2.0
>
>
> A query that causes a junction to form with a compiled in clause may throw 
> the following exception: 
> java.lang.ClassCastException: 
> org.apache.geode.cache.query.internal.CompiledIn cannot be cast to 
> org.apache.geode.cache.query.internal.CompiledJunction
>   at 
> org.apache.geode.cache.query.internal.AbstractGroupOrRangeJunction.(AbstractGroupOrRangeJunction.java:78)
>   at 
> org.apache.geode.cache.query.internal.GroupJunction.(GroupJunction.java:55)
>   at 
> org.apache.geode.cache.query.internal.GroupJunction.recreateFromOld(GroupJunction.java:61)
>   at 
> org.apache.geode.cache.query.internal.CompositeGroupJunction.evaluateAndJunction(CompositeGroupJunction.java:348)
>   at 
> org.apache.geode.cache.query.internal.CompositeGroupJunction.filterEvaluate(CompositeGroupJunction.java:93)
>   at 
> org.apache.geode.cache.query.internal.CompiledJunction.filterEvaluate(CompiledJunction.java:187)
>   at 
> org.apache.geode.cache.query.internal.CompiledSelect.evaluate(CompiledSelect.java:545)
>   at 
> org.apache.geode.cache.query.internal.CompiledSelect.evaluate(CompiledSelect.java:57)
>   at 
> org.apache.geode.cache.query.internal.DefaultQuery.executeUsingContext(DefaultQuery.java:579)
>   at 
> org.apache.geode.cache.query.internal.DefaultQuery.execute(DefaultQuery.java:391)
>   at 
> org.apache.geode.cache.query.internal.DefaultQuery.execute(DefaultQuery.java:323)
>   at 
> org.apache.geode.cache.query.QueryJUnitTest.creatingACompiledJunctionWithACompiledInClauseDoesNotThrowException(QueryJUnitTest.java:334)
>   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:483)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
>   at 
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:117)
>   at 
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:42)
>   at 
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:262)
>   at 
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:84)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

[jira] [Commented] (GEODE-2617) LuceneResultStruct should be Serializable

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2617:


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

GEODE-2617: make LuceneResultStruct serializable


> LuceneResultStruct should be Serializable
> -
>
> Key: GEODE-2617
> URL: https://issues.apache.org/jira/browse/GEODE-2617
> Project: Geode
>  Issue Type: Bug
>Reporter: xiaojian zhou
>Assignee: xiaojian zhou
>
> let LuceneResultStruct to be Serializable, then customer does not have to 
> defined their Serializable class to hold result.



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

[jira] [Commented] (GEODE-2621) CI Failure: ExportLogsDUnitTest.testExportWithStartAndEndDateTimeFiltering

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2621:


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

GEODE-2621: Reduce time sensitivity of ExportLogsDUnitTest


> CI Failure: ExportLogsDUnitTest.testExportWithStartAndEndDateTimeFiltering
> --
>
> Key: GEODE-2621
> URL: https://issues.apache.org/jira/browse/GEODE-2621
> Project: Geode
>  Issue Type: Bug
>  Components: management
>Affects Versions: 1.1.0
>Reporter: Jared Stewart
>Assignee: Jared Stewart
>Priority: Minor
>  Labels: CI, Flaky
>
> {code}
> See 
> 
> Changes:
> [jiliao] GEODE-2267: mark local time sensitive tests as flaky
> [khowe] GEODE-2488: Remove test from flaky category
> [nnag] GEODE-2596: Lucene metrics moved to public API
> [nnag] GEODE-2604: Added javadoc comments to LuceneIndexMetrics.java
> [nnag] GEODE-2604: Added measurement units to the javadoc comments
> --
> [...truncated 99.83 KB...]
> :geode-core:flakyTest
> org.apache.geode.management.internal.cli.commands.ExportLogsDUnitTest > 
> testExportWithStartAndEndDateTimeFiltering FAILED
>java.lang.AssertionError: 
>Expected size:<3> but was:<1> in:
><[/tmp/junit3849272601382305906/unzippedLogs/server-2]>
>at 
> org.apache.geode.management.internal.cli.commands.ExportLogsDUnitTest.verifyZipFileContents(ExportLogsDUnitTest.java:227)
>at 
> org.apache.geode.management.internal.cli.commands.ExportLogsDUnitTest.testExportWithStartAndEndDateTimeFiltering(ExportLogsDUnitTest.java:157)
> {code}



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

[jira] [Commented] (GEODE-1198) CI Failure: DistributedSystemDUnitTest.testConflictingUDPPort

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-1198:


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

GEODE-1198: refactor test with before/after and cleanup use of ports


> CI Failure: DistributedSystemDUnitTest.testConflictingUDPPort
> -
>
> Key: GEODE-1198
> URL: https://issues.apache.org/jira/browse/GEODE-1198
> Project: Geode
>  Issue Type: Bug
>  Components: membership, tests
>Reporter: Jinmei Liao
>Assignee: Kirk Lund
>  Labels: Flaky
> Fix For: 1.2.0
>
>
> Geode_develop_DistributedTests/2178/
> Revision: 7413804dec6acc1077618d50459e07200ced8336
> com.gemstone.gemfire.test.dunit.RMIException: While invoking 
> com.gemstone.gemfire.distributed.DistributedSystemDUnitTest$2.run in VM 1 
> running on Host rooktwo.gemstone.com with 4 VMs
>   at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:439)
>   at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:381)
>   at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:317)
>   at 
> com.gemstone.gemfire.distributed.DistributedSystemDUnitTest.testConflictingUDPPort(DistributedSystemDUnitTest.java:380)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:105)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:56)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:64)
>   at 
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:50)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.messaging.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
>   at 
> org.gradle.messaging.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
>   at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
>   at 
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:106)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.Na

[jira] [Commented] (GEODE-2267) Add gfsh command to export stat files

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2267:


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

GEODE-2267: Enhance server/locator startup rules

* be able to return the rule itself so that we can start the server/locator at 
rule declaration time.
* rearrange the class structure
* do not delete the workingDir if the rule is created with a workingDir (then 
it's up for the caller to delete it)


> Add gfsh command to export stat files
> -
>
> Key: GEODE-2267
> URL: https://issues.apache.org/jira/browse/GEODE-2267
> Project: Geode
>  Issue Type: New Feature
>  Components: configuration, gfsh
>Reporter: Diane Hardman
>Assignee: Kirk Lund
>  Labels: ExportClusterArtifacts, export, gfsh, logging, statistics
>
> We would like a single gfsh command to collect and export all logfiles and 
> stat files into a single package that will be returned to the gfsh client 
> machine. This package (zipfile) can then be saved and attached to emails and 
> Jira tickets to help evaluate the Geode cluster status.



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

[jira] [Commented] (GEODE-2614) Build generates javadoc warnings

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2614:


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

GEODE-2614: fix javadoc warnings


> Build generates javadoc warnings
> 
>
> Key: GEODE-2614
> URL: https://issues.apache.org/jira/browse/GEODE-2614
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh, jmx
>Reporter: Kirk Lund
>Assignee: Jinmei Liao
>  Labels: javadocs
> Fix For: 1.2.0
>
>
> {noformat}
> /Users/klund/dev/geode/geode-core/src/main/java/org/apache/geode/management/internal/cli/util/LogExporter.java:56:
>  warning - @param argument "logFilter:" is not a parameter name.
> /Users/klund/dev/geode/geode-core/src/main/java/org/apache/geode/management/internal/cli/util/LogExporter.java:56:
>  warning - @param argument "baseLogFile:" is not a parameter name.
> /Users/klund/dev/geode/geode-core/src/main/java/org/apache/geode/management/internal/cli/util/LogExporter.java:56:
>  warning - @param argument "baseStatsFile:" is not a parameter name.
> /Users/klund/dev/geode/geode-core/src/main/java/org/apache/geode/management/internal/cli/CliAroundInterceptor.java:45:
>  warning - @param argument "tempFile:" is not a parameter name.
> {noformat}



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

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

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2539:


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

GEODE-2539: Upgrading Jetty causes RestSecurityItegrationTest to fail


> 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
>Assignee: Kevin Duling
>
> 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:1

[jira] [Commented] (GEODE-2614) Build generates javadoc warnings

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2614:


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

GEODE-2614: fix javadoc warnings - spotless


> Build generates javadoc warnings
> 
>
> Key: GEODE-2614
> URL: https://issues.apache.org/jira/browse/GEODE-2614
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh, jmx
>Reporter: Kirk Lund
>Assignee: Jinmei Liao
>  Labels: javadocs
> Fix For: 1.2.0
>
>
> {noformat}
> /Users/klund/dev/geode/geode-core/src/main/java/org/apache/geode/management/internal/cli/util/LogExporter.java:56:
>  warning - @param argument "logFilter:" is not a parameter name.
> /Users/klund/dev/geode/geode-core/src/main/java/org/apache/geode/management/internal/cli/util/LogExporter.java:56:
>  warning - @param argument "baseLogFile:" is not a parameter name.
> /Users/klund/dev/geode/geode-core/src/main/java/org/apache/geode/management/internal/cli/util/LogExporter.java:56:
>  warning - @param argument "baseStatsFile:" is not a parameter name.
> /Users/klund/dev/geode/geode-core/src/main/java/org/apache/geode/management/internal/cli/CliAroundInterceptor.java:45:
>  warning - @param argument "tempFile:" is not a parameter name.
> {noformat}



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

[jira] [Commented] (GEODE-1198) CI Failure: DistributedSystemDUnitTest.testConflictingUDPPort

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-1198:


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

GEODE-1198: add todo comment to dubious test


> CI Failure: DistributedSystemDUnitTest.testConflictingUDPPort
> -
>
> Key: GEODE-1198
> URL: https://issues.apache.org/jira/browse/GEODE-1198
> Project: Geode
>  Issue Type: Bug
>  Components: membership, tests
>Reporter: Jinmei Liao
>Assignee: Kirk Lund
>  Labels: Flaky
> Fix For: 1.2.0
>
>
> Geode_develop_DistributedTests/2178/
> Revision: 7413804dec6acc1077618d50459e07200ced8336
> com.gemstone.gemfire.test.dunit.RMIException: While invoking 
> com.gemstone.gemfire.distributed.DistributedSystemDUnitTest$2.run in VM 1 
> running on Host rooktwo.gemstone.com with 4 VMs
>   at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:439)
>   at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:381)
>   at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:317)
>   at 
> com.gemstone.gemfire.distributed.DistributedSystemDUnitTest.testConflictingUDPPort(DistributedSystemDUnitTest.java:380)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:105)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:56)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:64)
>   at 
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:50)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.messaging.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
>   at 
> org.gradle.messaging.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
>   at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
>   at 
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:106)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.i

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

[Kevin Duling (JIRA)]

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

Kevin Duling resolved GEODE-2539.
-
   Resolution: Fixed
Fix Version/s: 1.2.0

> 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
>Assignee: Kevin Duling
> Fix For: 1.2.0
>
>
> 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, 2 failed
> :geode-assembly:integrationTest FAILED
> {noformat}



--
This message was sent by At

[jira] [Created] (GEODE-2633) When turning on fine logging, GEODE logs the keystore password in clear text

[Kevin Duling (JIRA)]

Kevin Duling created GEODE-2633:
---

 Summary: When turning on fine logging, GEODE logs the keystore 
password in clear text
 Key: GEODE-2633
 URL: https://issues.apache.org/jira/browse/GEODE-2633
 Project: Geode
  Issue Type: Bug
  Components: logging
Reporter: Kevin Duling


When turning on fine logging GEODE logs the keystore password in clear text.




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

[jira] [Updated] (GEODE-2633) When turning on fine logging, GEODE logs the keystore password in clear text

[Kevin Duling (JIRA)]

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

Kevin Duling updated GEODE-2633:

Component/s: gfsh

> When turning on fine logging, GEODE logs the keystore password in clear text
> 
>
> Key: GEODE-2633
> URL: https://issues.apache.org/jira/browse/GEODE-2633
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh, logging
>Reporter: Kevin Duling
>Assignee: Kevin Duling
>
> When turning on fine logging GEODE logs the keystore password in clear text.



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

[jira] [Assigned] (GEODE-2633) When turning on fine logging, GEODE logs the keystore password in clear text

[Kevin Duling (JIRA)]

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

Kevin Duling reassigned GEODE-2633:
---

Assignee: Kevin Duling

> When turning on fine logging, GEODE logs the keystore password in clear text
> 
>
> Key: GEODE-2633
> URL: https://issues.apache.org/jira/browse/GEODE-2633
> Project: Geode
>  Issue Type: Bug
>  Components: logging
>Reporter: Kevin Duling
>Assignee: Kevin Duling
>
> When turning on fine logging GEODE logs the keystore password in clear text.



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

Review Request 57431: GEODE-2633: When turning on fine logging, GEODE logs the keystore password in clear text

[Kevin Duling]

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

Review request for geode, Jinmei Liao, Jared Stewart, Ken Howe, and Kirk Lund.


Repository: geode


Description
---

GEODE-2633: When turning on fine logging, GEODE logs the keystore password in 
clear text


Diffs
-

  geode-core/src/main/java/org/apache/geode/internal/net/SocketCreator.java 
742e7f3e93e595844675d0789b995e4ceb4431ac 
  geode-core/src/main/java/org/apache/geode/internal/util/ArgumentRedactor.java 
419f3f976159e601c95a2042bafd96cc9fe9465f 


Diff: https://reviews.apache.org/r/57431/diff/1/


Testing
---

precheckin running


Thanks,

Kevin Duling

[jira] [Created] (GEODE-2634) gfsh export logs command should be able to filter logs on log-level

[Swapnil Bawaskar (JIRA)]

Swapnil Bawaskar created GEODE-2634:
---

 Summary: gfsh export logs command should be able to filter logs on 
log-level
 Key: GEODE-2634
 URL: https://issues.apache.org/jira/browse/GEODE-2634
 Project: Geode
  Issue Type: Sub-task
  Components: gfsh
Reporter: Swapnil Bawaskar


If I try to filter the exported logs by a log level, I get the following 
exceptions:
{{{
gfsh>export logs --dir=tmp --log-level=config
Invalid log level: config

gfsh>export logs --dir=tmp --log-level=config
Invalid log level: config

gfsh>export logs --dir=tmp --log-level=warning
Invalid log level: warning
}}}



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

Re: Review Request 57431: GEODE-2633: When turning on fine logging, GEODE logs the keystore password in clear text

[Jinmei Liao]

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



Any test changes? We probably can create a integrated/dunit test that would 
start a server with those ssl properties (including passwords) turned on, and 
have debug level truned on, and security truned on as well, and have gfsh 
connect to it using username and password, and see if any of the password show 
up in the logs.

- Jinmei Liao


On March 8, 2017, 8:58 p.m., Kevin Duling wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/57431/
> ---
> 
> (Updated March 8, 2017, 8:58 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Jared Stewart, Ken Howe, and Kirk Lund.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2633: When turning on fine logging, GEODE logs the keystore password in 
> clear text
> 
> 
> Diffs
> -
> 
>   geode-core/src/main/java/org/apache/geode/internal/net/SocketCreator.java 
> 742e7f3e93e595844675d0789b995e4ceb4431ac 
>   
> geode-core/src/main/java/org/apache/geode/internal/util/ArgumentRedactor.java 
> 419f3f976159e601c95a2042bafd96cc9fe9465f 
> 
> 
> Diff: https://reviews.apache.org/r/57431/diff/1/
> 
> 
> Testing
> ---
> 
> precheckin running
> 
> 
> Thanks,
> 
> Kevin Duling
> 
>

[jira] [Commented] (GEODE-2616) A colocated paritioned region will leak memory when it is closed or destroyed

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2616:


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

GEODE-2616: fix leak in colocated region removal

postDestroyRegion now removes itself from colocated parent colocatedByList


> A colocated paritioned region will leak memory when it is closed or destroyed
> -
>
> Key: GEODE-2616
> URL: https://issues.apache.org/jira/browse/GEODE-2616
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Affects Versions: 1.1.0
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
>
> When a colocated partitioned region is created it registers itself with the 
> parent region it is colocated with. When that same region is closed or 
> destroyed it does not deregister itself from the parent.
> This results in a memory leak that remains until the parent region is itself 
> closed or destroyed.



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

[jira] [Assigned] (GEODE-2594) Remove optional usage of Attach API

[Kirk Lund (JIRA)]

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

Kirk Lund reassigned GEODE-2594:


Assignee: Kirk Lund

> Remove optional usage of Attach API
> ---
>
> Key: GEODE-2594
> URL: https://issues.apache.org/jira/browse/GEODE-2594
> Project: Geode
>  Issue Type: Improvement
>  Components: gfsh
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>  Labels: gfsh
>
> This is a request to remove our optional usage of Attach API.
> Users keep running into issues caused by GFSH using the Attach API. If the 
> user kills a GemFire process that was started by GFSH, the Attach API leaves 
> a java_pid file in /tmp which prevents the Attach API from working with any 
> future JVMs that reuse that pid. Most users also want to use a JRE without 
> the tools.jar.
> The only functionality that will be removed is status and stop command 
> support for --pid option.



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

Re: Review Request 57431: GEODE-2633: When turning on fine logging, GEODE logs the keystore password in clear text

[Kevin Duling]

> On March 8, 2017, 1:16 p.m., Jinmei Liao wrote:
> > Any test changes? We probably can create a integrated/dunit test that would 
> > start a server with those ssl properties (including passwords) turned on, 
> > and have debug level truned on, and security truned on as well, and have 
> > gfsh connect to it using username and password, and see if any of the 
> > password show up in the logs.

`ArgumentRedactorJUnitTest` already has 85% method coverage and 95% line 
coverage of `ArgumentRedactor`.  `SocketCreator.printConfig()` is a void method 
which only writes out to the log file.  I could add a specific test for the 
expected ssl property, but it's already covered by the comparison 
`compareKey.toLowerCase().contains("password");`


- Kevin


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


On March 8, 2017, 12:58 p.m., Kevin Duling wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/57431/
> ---
> 
> (Updated March 8, 2017, 12:58 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Jared Stewart, Ken Howe, and Kirk Lund.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2633: When turning on fine logging, GEODE logs the keystore password in 
> clear text
> 
> 
> Diffs
> -
> 
>   geode-core/src/main/java/org/apache/geode/internal/net/SocketCreator.java 
> 742e7f3e93e595844675d0789b995e4ceb4431ac 
>   
> geode-core/src/main/java/org/apache/geode/internal/util/ArgumentRedactor.java 
> 419f3f976159e601c95a2042bafd96cc9fe9465f 
> 
> 
> Diff: https://reviews.apache.org/r/57431/diff/1/
> 
> 
> Testing
> ---
> 
> precheckin running
> 
> 
> Thanks,
> 
> Kevin Duling
> 
>

Re: Review Request 57431: GEODE-2633: When turning on fine logging, GEODE logs the keystore password in clear text

[Jinmei Liao]

> On March 8, 2017, 9:16 p.m., Jinmei Liao wrote:
> > Any test changes? We probably can create a integrated/dunit test that would 
> > start a server with those ssl properties (including passwords) turned on, 
> > and have debug level truned on, and security truned on as well, and have 
> > gfsh connect to it using username and password, and see if any of the 
> > password show up in the logs.
> 
> Kevin Duling wrote:
> `ArgumentRedactorJUnitTest` already has 85% method coverage and 95% line 
> coverage of `ArgumentRedactor`.  `SocketCreator.printConfig()` is a void 
> method which only writes out to the log file.  I could add a specific test 
> for the expected ssl property, but it's already covered by the comparison 
> `compareKey.toLowerCase().contains("password");`

ArugmentRedactor is defintely doing the right thing since we have test coverage 
on that. It's the SocketCreator that is the problem here.


- Jinmei


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


On March 8, 2017, 8:58 p.m., Kevin Duling wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/57431/
> ---
> 
> (Updated March 8, 2017, 8:58 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Jared Stewart, Ken Howe, and Kirk Lund.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2633: When turning on fine logging, GEODE logs the keystore password in 
> clear text
> 
> 
> Diffs
> -
> 
>   geode-core/src/main/java/org/apache/geode/internal/net/SocketCreator.java 
> 742e7f3e93e595844675d0789b995e4ceb4431ac 
>   
> geode-core/src/main/java/org/apache/geode/internal/util/ArgumentRedactor.java 
> 419f3f976159e601c95a2042bafd96cc9fe9465f 
> 
> 
> Diff: https://reviews.apache.org/r/57431/diff/1/
> 
> 
> Testing
> ---
> 
> precheckin running
> 
> 
> Thanks,
> 
> Kevin Duling
> 
>

[jira] [Created] (GEODE-2635) Create Lucene DUnit tests to check eviction attributes

[nabarun (JIRA)]

nabarun created GEODE-2635:
--

 Summary: Create Lucene DUnit tests to check eviction attributes
 Key: GEODE-2635
 URL: https://issues.apache.org/jira/browse/GEODE-2635
 Project: Geode
  Issue Type: Bug
  Components: lucene
Reporter: nabarun


Create LuceneDunit tests which tests eviction with both local destroy and 
overflow to disk



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

A force push happened to geode-native develop!?!

[Dan Smith]

Karen and I just spent a long time tracking down weird git history in her
checkout to discover that someone did a force push of the geode-native
develop. That's not cool, because it screws over anyone with a copy of the
branch and we potentially lost history.

I think we need to do two things.

1) Block force pushes on any shared branches (develop, master, release-*).
If we are in agreement, I'll file a JIRA with INFRA

2) Figure out what to with geode-native develop. It looks like there have
been commits since the force push. Do we keep what is on the branch now, or
try to put it back to what it was?

-Dan


From: jbarr...@apache.org

4:57 PM (20 hours ago)

to commits
Repository: geode-native
Updated Branches:
  refs/heads/develop aff706be2 -> 06e8f39a0 (forced update)

Re: A force push happened to geode-native develop!?!

[Jacob Barrett]

The force push was done to clean up a bunch of commits that broke develop
on the longer list of targeted platforms and moved them to another branch.

It could have been done with a series of reverts. Sorry for the confusion.
Other pulls pending on Geode native were corrected. I did not see a pull
for Karen's changes or I would have reached out to have them corrected.

I disagree on the blocking of force commits. Especially at his early stage
of source cleanup.

-Jake

On Wed, Mar 8, 2017 at 1:48 PM Dan Smith  wrote:

> Karen and I just spent a long time tracking down weird git history in her
> checkout to discover that someone did a force push of the geode-native
> develop. That's not cool, because it screws over anyone with a copy of the
> branch and we potentially lost history.
>
> I think we need to do two things.
>
> 1) Block force pushes on any shared branches (develop, master, release-*).
> If we are in agreement, I'll file a JIRA with INFRA
>
> 2) Figure out what to with geode-native develop. It looks like there have
> been commits since the force push. Do we keep what is on the branch now, or
> try to put it back to what it was?
>
> -Dan
>
>
> From: jbarr...@apache.org
>
> 4:57 PM (20 hours ago)
>
> to commits
> Repository: geode-native
> Updated Branches:
>   refs/heads/develop aff706be2 -> 06e8f39a0 (forced update)
>

[jira] [Resolved] (GEODE-2616) A colocated paritioned region will leak memory when it is closed or destroyed

[Darrel Schneider (JIRA)]

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

Darrel Schneider resolved GEODE-2616.
-
   Resolution: Fixed
Fix Version/s: 1.2.0

> A colocated paritioned region will leak memory when it is closed or destroyed
> -
>
> Key: GEODE-2616
> URL: https://issues.apache.org/jira/browse/GEODE-2616
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Affects Versions: 1.1.0
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
> Fix For: 1.2.0
>
>
> When a colocated partitioned region is created it registers itself with the 
> parent region it is colocated with. When that same region is closed or 
> destroyed it does not deregister itself from the parent.
> This results in a memory leak that remains until the parent region is itself 
> closed or destroyed.



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

[GitHub] geode-native pull request #49: GEODE-2513 Unbrand docs section on Preserving...

[karensmolermiller]

GitHub user karensmolermiller opened a pull request:

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

GEODE-2513 Unbrand docs section on Preserving Data

- Remove references to GemFire
- Fix typos
- Clarify links that leave the native-manual

@davebarnes97 @joeymcallister @echobravopapa @mmartell @PivotalSarge 
@dgkimura Please review this PR containing changes to the user manual.

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

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

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

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


commit 34c92b08df3696cef4a4b3a4c6c5857e14da4d08
Author: Karen Miller 
Date:   2017-03-08T20:11:02Z

GEODE-2513 Unbrand docs section on Preserving Data

- Remove references to GemFire
- Fix typos
- Clarify links that leave the native-manual




---
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&focusedCommentId=15902046#comment-15902046
 ] 

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

GitHub user karensmolermiller opened a pull request:

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

GEODE-2513 Unbrand docs section on Preserving Data

- Remove references to GemFire
- Fix typos
- Clarify links that leave the native-manual

@davebarnes97 @joeymcallister @echobravopapa @mmartell @PivotalSarge 
@dgkimura Please review this PR containing changes to the user manual.

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

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

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

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


commit 34c92b08df3696cef4a4b3a4c6c5857e14da4d08
Author: Karen Miller 
Date:   2017-03-08T20:11:02Z

GEODE-2513 Unbrand docs section on Preserving Data

- Remove references to GemFire
- Fix typos
- Clarify links that leave the native-manual




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

Re: Storing object in deserialized form in geode cache

[Darrel Schneider]

Mike is correct that the first time you ask a VMCachedDeserializable for
the deserialized value that the deserialized value will "stick" in the
VMCachedDeserializable. If anyone then asks that VMCachedDeserializable for
the serialized value it has to serialize it each time since it is now stuck
as deserialized.

Instead of doing inplace modification you might want to check out geode's
Delta interface. It keeps the values in object form and allows the value to
be distributed to be a subset of the full object that will be applied to
the full object on other members.

Also off-heap regions always store their values serialized.

If your value is a "byte []" then it will not be wrapped by a
VMCachedDeserializable. For "byte []" geode just stores a reference to the
byte array.

You might also want to checkout geode PDX serialization. It allows you to
keep the data serialized on the server and still be able to fetch and
modify fields on the serialized data.

On Wed, Mar 8, 2017 at 10:41 AM, Michael Stolz  wrote:

> The rule is, if you deserialize the object in the server side, Geode keeps
> the deserialized version of it around.
>
> As for updating in place...this is the position that the docs for
> Commercial GemFire take on that subject:
>
> "If you do not have the cache copy-on-read attribute set to true, do not
> change the objects returned from the Java entry access methods. Instead,
> create a copy of the object, then modify the copy and pass it to the Java
> put method. Modifying a value in place bypasses the entire distribution
> framework provided by GemFire, including cache listeners and expiration
> activities, and can produce undesired results."
>
> Of course if that's exactly the behavior you WANT, then set
> copy-on-read=false.
>
>
>
> --
> Mike Stolz
> Principal Engineer, GemFire Product Manager
> Mobile: +1-631-835-4771
>
> On Wed, Mar 8, 2017 at 1:37 AM, Deepak Dixit 
> wrote:
>
> > Hello Geode Team,
> >
> > I am working on a use case where I want to store the java object. I want
> to
> > avoid the serialization and deserialization while reading on server
> > (function execution).
> > Also while updating I would like to update in-place rather than to create
> > copy of object, modify and store it again in underlying map.
> >
> > Based on my current understanding, every object is wrapped in
> > "VMCachedDeserializable" and serialized / deserialized while doing
> get/put.
> >
> > Kindly advice the way with which I can store object in deserialized form
> in
> > cache and do in place modifications.
> >
> > Thanks,
> > Deepak
> >
>

[VOTE] Marking Redis Adapter as Experimental

[Galen M O'Sullivan]

Hi all,

I think that we should mark the Redis adapter as experimental. This
functionality comes from the initial code grant from GemFire. It is
mentioned in the "Experimental" section of the GemFire docs [1], and as far
as I can tell, the only reason it hasn't been marked as experimental in
Geode is because no one put the annotation on when the @Experimental tag
was introduced.

The Redis adapter's performance on collection operations is pretty bad
(think 1% of Redis on a single-server configuration), and there are some
bugs outstanding (for example, [2]), so I don't think it's really ready for
general use.

What do you all think? Is anyone out there using the Redis adapter? Should
it be considered breaking to change it just because it's been released when
it wasn't marked experimental? Should we just go ahead and change it
already?

Thanks,
Galen

[1]: http://gemfire.docs.pivotal.io/geode/tools_modules/redis_adapter.html
[2]: https://issues.apache.org/jira/browse/GEODE-2473

Re: [VOTE] Marking Redis Adapter as Experimental

[Michael Stolz]

+1 to marking it experimental now

Once we do that I think it will be fine for the community to make breaking
changes to it if we need to.

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

On Wed, Mar 8, 2017 at 5:08 PM, Galen M O'Sullivan 
wrote:

> Hi all,
>
> I think that we should mark the Redis adapter as experimental. This
> functionality comes from the initial code grant from GemFire. It is
> mentioned in the "Experimental" section of the GemFire docs [1], and as far
> as I can tell, the only reason it hasn't been marked as experimental in
> Geode is because no one put the annotation on when the @Experimental tag
> was introduced.
>
> The Redis adapter's performance on collection operations is pretty bad
> (think 1% of Redis on a single-server configuration), and there are some
> bugs outstanding (for example, [2]), so I don't think it's really ready for
> general use.
>
> What do you all think? Is anyone out there using the Redis adapter? Should
> it be considered breaking to change it just because it's been released when
> it wasn't marked experimental? Should we just go ahead and change it
> already?
>
> Thanks,
> Galen
>
> [1]: http://gemfire.docs.pivotal.io/geode/tools_modules/redis_adapter.html
> [2]: https://issues.apache.org/jira/browse/GEODE-2473
>

[jira] [Created] (GEODE-2636) Update exemplary code to follow library renaming

[Michael Dodge (JIRA)]

Michael Dodge created GEODE-2636:


 Summary: Update exemplary code to follow library renaming
 Key: GEODE-2636
 URL: https://issues.apache.org/jira/browse/GEODE-2636
 Project: Geode
  Issue Type: Bug
  Components: native client
Reporter: Michael Dodge


The work done for GEODE-2508 needs to be accommodated in the template and 
quickstart code.



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

[jira] [Assigned] (GEODE-2636) Update exemplary code to follow library renaming

[Michael Dodge (JIRA)]

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

Michael Dodge reassigned GEODE-2636:


Assignee: Michael Dodge

> Update exemplary code to follow library renaming
> 
>
> Key: GEODE-2636
> URL: https://issues.apache.org/jira/browse/GEODE-2636
> Project: Geode
>  Issue Type: Bug
>  Components: native client
>Reporter: Michael Dodge
>Assignee: Michael Dodge
>
> The work done for GEODE-2508 needs to be accommodated in the template and 
> quickstart code.



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

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

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2539:


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

GEODE-2539: revert jetty version change for now


> 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
>Assignee: Kevin Duling
> Fix For: 1.2.0
>
>
> 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(RedirectEx

[jira] [Assigned] (GEODE-2637) LuceneQueryFactory.setResultLimit() method should match LuceneQuery.getLimit()

[Shelley Lynn Hughes-Godfrey (JIRA)]

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

Shelley Lynn Hughes-Godfrey reassigned GEODE-2637:
--

Assignee: Shelley Lynn Hughes-Godfrey

> LuceneQueryFactory.setResultLimit() method should match LuceneQuery.getLimit()
> --
>
> Key: GEODE-2637
> URL: https://issues.apache.org/jira/browse/GEODE-2637
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Affects Versions: 1.2.0
>Reporter: Shelley Lynn Hughes-Godfrey
>Assignee: Shelley Lynn Hughes-Godfrey
>
> In the Lucene docs located here:
>  https://cwiki.apache.org/confluence/display/GEODE/Text+Search+With+Lucene
> we see that we control the number of results from the lucene query via 
> LuceneQueryFactory.setLimit() which corresponds directly with the 
> LuceneQuery.getLimit() method.
> However, this has been implemented as LuceneQueryFactory.setResultLimit().
> This needs to be changed to setLimit().



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

[jira] [Created] (GEODE-2637) LuceneQueryFactory.setResultLimit() method should match LuceneQuery.getLimit()

[Shelley Lynn Hughes-Godfrey (JIRA)]

Shelley Lynn Hughes-Godfrey created GEODE-2637:
--

 Summary: LuceneQueryFactory.setResultLimit() method should match 
LuceneQuery.getLimit()
 Key: GEODE-2637
 URL: https://issues.apache.org/jira/browse/GEODE-2637
 Project: Geode
  Issue Type: Bug
  Components: lucene
Reporter: Shelley Lynn Hughes-Godfrey


In the Lucene docs located here:
 https://cwiki.apache.org/confluence/display/GEODE/Text+Search+With+Lucene
we see that we control the number of results from the lucene query via 
LuceneQueryFactory.setLimit() which corresponds directly with the 
LuceneQuery.getLimit() method.

However, this has been implemented as LuceneQueryFactory.setResultLimit().
This needs to be changed to setLimit().



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

[jira] [Updated] (GEODE-2637) LuceneQueryFactory.setResultLimit() method should match LuceneQuery.getLimit()

[Shelley Lynn Hughes-Godfrey (JIRA)]

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

Shelley Lynn Hughes-Godfrey updated GEODE-2637:
---
Affects Version/s: 1.2.0

> LuceneQueryFactory.setResultLimit() method should match LuceneQuery.getLimit()
> --
>
> Key: GEODE-2637
> URL: https://issues.apache.org/jira/browse/GEODE-2637
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Affects Versions: 1.2.0
>Reporter: Shelley Lynn Hughes-Godfrey
>
> In the Lucene docs located here:
>  https://cwiki.apache.org/confluence/display/GEODE/Text+Search+With+Lucene
> we see that we control the number of results from the lucene query via 
> LuceneQueryFactory.setLimit() which corresponds directly with the 
> LuceneQuery.getLimit() method.
> However, this has been implemented as LuceneQueryFactory.setResultLimit().
> This needs to be changed to setLimit().



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

[jira] [Commented] (GEODE-2553) Lucene search hangs on recreated region with no data

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2553:


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

GEODE-2553: Closed IndexRepositories when deleting an index


> Lucene search hangs on recreated region with no data
> 
>
> Key: GEODE-2553
> URL: https://issues.apache.org/jira/browse/GEODE-2553
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Diane Hardman
> Fix For: 1.2.0
>
> Attachments: server50505.log, stack.log
>
>
> While manually testing in gfsh the process of deleting Lucene indexes, 
> deleting the region, creating new indexes and a new empty region, I was able 
> to hang gfsh while doing a Lucene search on the new region with no data.
> Here are the steps I used:
> _ __
>/ _/ __/ __/ // /
>   / /  __/ /___  /_  / _  / 
>  / /__/ / /  _/ / // /  
> /__/_/  /__/_//_/1.2.0-SNAPSHOT
> Monitor and Manage Apache Geode
> gfsh>start locator --name=locator1 --port=12345
> gfsh>start server --name=server50505 --server-port=50505 
> --locators=localhost[12345] --start-rest-api --http-service-port=8080 
> --http-service-bind-address=localhost
> gfsh>create lucene index --name=testIndex --region=testRegion 
> --field=__REGION_VALUE_FIELD
> gfsh>create lucene index --name=testIndex2 --region=testRegion 
> gfsh>list lucene indexes --with-stats
> gfsh>create region --name=testRegion --type=PARTITION_PERSISTENT
> gfsh>put --key=1 --value=value1 --region=testRegion
> gfsh>put --key=2 --value=value2 --region=testRegion
> gfsh>put --key=3 --value=value3 --region=testRegion
> gfsh>search lucene --name=testIndex --region=/testRegion 
> --queryStrings=value* --defaultField=__REGION_VALUE_FIELD
> gfsh>search lucene --name=testIndex2 --region=/testRegion 
> --queryStrings=value* --defaultField=__REGION_VALUE_FIELD
> gfsh>destroy lucene index --region=/testRegion --name=testIndex
> gfsh>list lucene indexes --with-stats
> gfsh>search lucene --name=testIndex2 --region=/testRegion 
> --queryStrings=value* --defaultField=__REGION_VALUE_FIELD
> gfsh>search lucene --name=testIndex --region=/testRegion 
> --queryStrings=value* --defaultField=__REGION_VALUE_FIELD
> 
> gfsh>destroy lucene index --region=/testRegion
> gfsh>list lucene indexes --with-stats
> gfsh>destroy region --name=/testRegion
> gfsh>create lucene index --name=testIndex --region=testRegion 
> gfsh>create lucene index --name=testIndex2 --region=testRegion 
> --field=__REGION_VALUE_FIELD
> gfsh>list lucene indexes --with-stats
> gfsh>create region --name=testRegion --type=PARTITION_PERSISTENT
> gfsh>search lucene --name=testIndex --region=/testRegion 
> --queryStrings=value* --defaultField=__REGION_VALUE_FIELD
> The gfsh process hangs at this point.
> I'll attach the stacktrace for the server.



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

Re: A force push happened to geode-native develop!?!

[Dan Smith]

You should never force push a shared branch, period.

It's just luck that no one has pushed the changes you intended to remove
*back* to develop. If someone has a copy of develop checked out and does a
pull, git will merge your new copy of develop with their old copy of
develop, and they'll push all that stuff right back. git revert is the only
way to go.

>I did not see a pull for Karen's changes or I would have reached out to
have them corrected.

We are an open source project. Lots of people may have a copy of develop,
and you won't know about it. It's not reasonable to break develop and
expect to be able to personally contact everyone who has a copy of it and
ask them to reset.

-Dan

On Wed, Mar 8, 2017 at 1:53 PM, Jacob Barrett  wrote:

> The force push was done to clean up a bunch of commits that broke develop
> on the longer list of targeted platforms and moved them to another branch.
>
> It could have been done with a series of reverts. Sorry for the confusion.
> Other pulls pending on Geode native were corrected. I did not see a pull
> for Karen's changes or I would have reached out to have them corrected.
>
> I disagree on the blocking of force commits. Especially at his early stage
> of source cleanup.
>
> -Jake
>
> On Wed, Mar 8, 2017 at 1:48 PM Dan Smith  wrote:
>
> > Karen and I just spent a long time tracking down weird git history in her
> > checkout to discover that someone did a force push of the geode-native
> > develop. That's not cool, because it screws over anyone with a copy of
> the
> > branch and we potentially lost history.
> >
> > I think we need to do two things.
> >
> > 1) Block force pushes on any shared branches (develop, master,
> release-*).
> > If we are in agreement, I'll file a JIRA with INFRA
> >
> > 2) Figure out what to with geode-native develop. It looks like there have
> > been commits since the force push. Do we keep what is on the branch now,
> or
> > try to put it back to what it was?
> >
> > -Dan
> >
> >
> > From: jbarr...@apache.org
> >
> > 4:57 PM (20 hours ago)
> >
> > to commits
> > Repository: geode-native
> > Updated Branches:
> >   refs/heads/develop aff706be2 -> 06e8f39a0 (forced update)
> >
>

Re: Review Request 57431: GEODE-2633: When turning on fine logging, GEODE logs the keystore password in clear text

[Kevin Duling]

> On March 8, 2017, 1:16 p.m., Jinmei Liao wrote:
> > Any test changes? We probably can create a integrated/dunit test that would 
> > start a server with those ssl properties (including passwords) turned on, 
> > and have debug level truned on, and security truned on as well, and have 
> > gfsh connect to it using username and password, and see if any of the 
> > password show up in the logs.
> 
> Kevin Duling wrote:
> `ArgumentRedactorJUnitTest` already has 85% method coverage and 95% line 
> coverage of `ArgumentRedactor`.  `SocketCreator.printConfig()` is a void 
> method which only writes out to the log file.  I could add a specific test 
> for the expected ssl property, but it's already covered by the comparison 
> `compareKey.toLowerCase().contains("password");`
> 
> Jinmei Liao wrote:
> ArugmentRedactor is defintely doing the right thing since we have test 
> coverage on that. It's the SocketCreator that is the problem here.

I disagree.  ArgumentRedactor just has to populate the StringBuilder with the 
correct string.  The only additional piece is calling the logger to write the 
file, which is Log4J, not SocketCreator.  I'm not clear on what additional 
testing would prove.

`RestSecurityWithSSLTest` is probably a good test to work from as it is an 
entry point for this code.


- Kevin


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


On March 8, 2017, 12:58 p.m., Kevin Duling wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/57431/
> ---
> 
> (Updated March 8, 2017, 12:58 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Jared Stewart, Ken Howe, and Kirk Lund.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2633: When turning on fine logging, GEODE logs the keystore password in 
> clear text
> 
> 
> Diffs
> -
> 
>   geode-core/src/main/java/org/apache/geode/internal/net/SocketCreator.java 
> 742e7f3e93e595844675d0789b995e4ceb4431ac 
>   
> geode-core/src/main/java/org/apache/geode/internal/util/ArgumentRedactor.java 
> 419f3f976159e601c95a2042bafd96cc9fe9465f 
> 
> 
> Diff: https://reviews.apache.org/r/57431/diff/1/
> 
> 
> Testing
> ---
> 
> precheckin running
> 
> 
> Thanks,
> 
> Kevin Duling
> 
>

[Spring CI] Spring Data GemFire > Nightly-ApacheGeode > #494 has FAILED (1 tests failed)

[Spring CI]

---
Spring Data GemFire > Nightly-ApacheGeode > #494 failed.
---
Scheduled
1/1682 tests failed.

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

-
Currently Responsible
-

No one is responsible for fixing this build.



--
Failing Jobs
--
  - Default Job (Default Stage): 1 of 1682 tests failed.




--
Tests
--
New Test Failures (1)
   - ApacheShiroRealmGeodeSecurityIntegrationTests: Authorized user

--
This message is automatically generated by Atlassian Bamboo

Re: [VOTE] Marking Redis Adapter as Experimental

[Dan Smith]

+1 for marking it experimental and going ahead with changing it.

-Dan

On Wed, Mar 8, 2017 at 2:21 PM, Michael Stolz  wrote:

> +1 to marking it experimental now
>
> Once we do that I think it will be fine for the community to make breaking
> changes to it if we need to.
>
> --
> Mike Stolz
> Principal Engineer, GemFire Product Manager
> Mobile: +1-631-835-4771
>
> On Wed, Mar 8, 2017 at 5:08 PM, Galen M O'Sullivan 
> wrote:
>
> > Hi all,
> >
> > I think that we should mark the Redis adapter as experimental. This
> > functionality comes from the initial code grant from GemFire. It is
> > mentioned in the "Experimental" section of the GemFire docs [1], and as
> far
> > as I can tell, the only reason it hasn't been marked as experimental in
> > Geode is because no one put the annotation on when the @Experimental tag
> > was introduced.
> >
> > The Redis adapter's performance on collection operations is pretty bad
> > (think 1% of Redis on a single-server configuration), and there are some
> > bugs outstanding (for example, [2]), so I don't think it's really ready
> for
> > general use.
> >
> > What do you all think? Is anyone out there using the Redis adapter?
> Should
> > it be considered breaking to change it just because it's been released
> when
> > it wasn't marked experimental? Should we just go ahead and change it
> > already?
> >
> > Thanks,
> > Galen
> >
> > [1]: http://gemfire.docs.pivotal.io/geode/tools_modules/redis_
> adapter.html
> > [2]: https://issues.apache.org/jira/browse/GEODE-2473
> >
>

Re: [VOTE] Marking Redis Adapter as Experimental

[Wayne Lund]

+1.  Good to know.  I was just talking to a potential customer this morning 
that’s intent on replacing voldemort with an IMDG and wanting to merge whatever 
solution with their current Redis use cases.  If its not ready I want to make 
sure I’m not giving bad information. 

Wayne Lund
Advisory Platform Architect
916.296.1893
wl...@pivotal.io

> On Mar 8, 2017, at 2:21 PM, Michael Stolz  wrote:
> 
> +1 to marking it experimental now
> 
> Once we do that I think it will be fine for the community to make breaking 
> changes to it if we need to.
> 
> --
> Mike Stolz
> Principal Engineer, GemFire Product Manager 
> Mobile: +1-631-835-4771
> 
> On Wed, Mar 8, 2017 at 5:08 PM, Galen M O'Sullivan  > wrote:
> Hi all,
> 
> I think that we should mark the Redis adapter as experimental. This 
> functionality comes from the initial code grant from GemFire. It is mentioned 
> in the "Experimental" section of the GemFire docs [1], and as far as I can 
> tell, the only reason it hasn't been marked as experimental in Geode is 
> because no one put the annotation on when the @Experimental tag was 
> introduced.
> 
> The Redis adapter's performance on collection operations is pretty bad (think 
> 1% of Redis on a single-server configuration), and there are some bugs 
> outstanding (for example, [2]), so I don't think it's really ready for 
> general use.
> 
> What do you all think? Is anyone out there using the Redis adapter? Should it 
> be considered breaking to change it just because it's been released when it 
> wasn't marked experimental? Should we just go ahead and change it already?
> 
> Thanks,
> Galen
>  
> [1]: http://gemfire.docs.pivotal.io/geode/tools_modules/redis_adapter.html 
> 
> [2]: https://issues.apache.org/jira/browse/GEODE-2473 
> 
> 

Re: A force push happened to geode-native develop!?!

[Jared Stewart]

+1 to blocking force pushes on shared branches.  It also would seem prudent to 
block 'git push —delete’ on shared branches if that isn’t already blocked.

> On Mar 8, 2017, at 1:48 PM, Dan Smith  wrote:
> 
> Karen and I just spent a long time tracking down weird git history in her
> checkout to discover that someone did a force push of the geode-native
> develop. That's not cool, because it screws over anyone with a copy of the
> branch and we potentially lost history.
> 
> I think we need to do two things.
> 
> 1) Block force pushes on any shared branches (develop, master, release-*).
> If we are in agreement, I'll file a JIRA with INFRA
> 
> 2) Figure out what to with geode-native develop. It looks like there have
> been commits since the force push. Do we keep what is on the branch now, or
> try to put it back to what it was?
> 
> -Dan
> 
> 
> From: jbarr...@apache.org
> 
> 4:57 PM (20 hours ago)
> 
> to commits
> Repository: geode-native
> Updated Branches:
>  refs/heads/develop aff706be2 -> 06e8f39a0 (forced update)

Re: A force push happened to geode-native develop!?!

[Dave Barnes]

> It also would seem prudent to block 'git push —delete’ on shared branches

Isn't that how we clean up feature branches?

On Wed, Mar 8, 2017 at 1:55 PM, Jared Stewart  wrote:

> +1 to blocking force pushes on shared branches.  It also would seem
> prudent to block 'git push —delete’ on shared branches if that isn’t
> already blocked.
>
> > On Mar 8, 2017, at 1:48 PM, Dan Smith  wrote:
> >
> > Karen and I just spent a long time tracking down weird git history in her
> > checkout to discover that someone did a force push of the geode-native
> > develop. That's not cool, because it screws over anyone with a copy of
> the
> > branch and we potentially lost history.
> >
> > I think we need to do two things.
> >
> > 1) Block force pushes on any shared branches (develop, master,
> release-*).
> > If we are in agreement, I'll file a JIRA with INFRA
> >
> > 2) Figure out what to with geode-native develop. It looks like there have
> > been commits since the force push. Do we keep what is on the branch now,
> or
> > try to put it back to what it was?
> >
> > -Dan
> >
> >
> > From: jbarr...@apache.org
> >
> > 4:57 PM (20 hours ago)
> >
> > to commits
> > Repository: geode-native
> > Updated Branches:
> >  refs/heads/develop aff706be2 -> 06e8f39a0 (forced update)
>
>

Re: A force push happened to geode-native develop!?!

[Jared Stewart]

When I say “shared branches”, I’m thinking of develop, master, and release-* as 
mentioned by Dan.


> On Mar 8, 2017, at 3:03 PM, Dave Barnes  wrote:
> 
>> It also would seem prudent to block 'git push —delete’ on shared branches
> 
> Isn't that how we clean up feature branches?
> 
> On Wed, Mar 8, 2017 at 1:55 PM, Jared Stewart  wrote:
> 
>> +1 to blocking force pushes on shared branches.  It also would seem
>> prudent to block 'git push —delete’ on shared branches if that isn’t
>> already blocked.
>> 
>>> On Mar 8, 2017, at 1:48 PM, Dan Smith  wrote:
>>> 
>>> Karen and I just spent a long time tracking down weird git history in her
>>> checkout to discover that someone did a force push of the geode-native
>>> develop. That's not cool, because it screws over anyone with a copy of
>> the
>>> branch and we potentially lost history.
>>> 
>>> I think we need to do two things.
>>> 
>>> 1) Block force pushes on any shared branches (develop, master,
>> release-*).
>>> If we are in agreement, I'll file a JIRA with INFRA
>>> 
>>> 2) Figure out what to with geode-native develop. It looks like there have
>>> been commits since the force push. Do we keep what is on the branch now,
>> or
>>> try to put it back to what it was?
>>> 
>>> -Dan
>>> 
>>> 
>>> From: jbarr...@apache.org
>>> 
>>> 4:57 PM (20 hours ago)
>>> 
>>> to commits
>>> Repository: geode-native
>>> Updated Branches:
>>> refs/heads/develop aff706be2 -> 06e8f39a0 (forced update)
>> 
>> 

Re: Review Request 57431: GEODE-2633: When turning on fine logging, GEODE logs the keystore password in clear text

[Jinmei Liao]

> On March 8, 2017, 9:16 p.m., Jinmei Liao wrote:
> > Any test changes? We probably can create a integrated/dunit test that would 
> > start a server with those ssl properties (including passwords) turned on, 
> > and have debug level truned on, and security truned on as well, and have 
> > gfsh connect to it using username and password, and see if any of the 
> > password show up in the logs.
> 
> Kevin Duling wrote:
> `ArgumentRedactorJUnitTest` already has 85% method coverage and 95% line 
> coverage of `ArgumentRedactor`.  `SocketCreator.printConfig()` is a void 
> method which only writes out to the log file.  I could add a specific test 
> for the expected ssl property, but it's already covered by the comparison 
> `compareKey.toLowerCase().contains("password");`
> 
> Jinmei Liao wrote:
> ArugmentRedactor is defintely doing the right thing since we have test 
> coverage on that. It's the SocketCreator that is the problem here.
> 
> Kevin Duling wrote:
> I disagree.  ArgumentRedactor just has to populate the StringBuilder with 
> the correct string.  The only additional piece is calling the logger to write 
> the file, which is Log4J, not SocketCreator.  I'm not clear on what 
> additional testing would prove.
> 
> `RestSecurityWithSSLTest` is probably a good test to work from as it is 
> an entry point for this code.
> 
> Jared Stewart wrote:
> I think the goal of a test for SocketCreator would be that if someone 
> reverts the changes to SocketCreator made by this commit, there should be a 
> test that fails.

My point as well. We should have a test that would fail without your changes in 
SocketCreator, and then passes when you put in the fix.


- Jinmei


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


On March 8, 2017, 8:58 p.m., Kevin Duling wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/57431/
> ---
> 
> (Updated March 8, 2017, 8:58 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Jared Stewart, Ken Howe, and Kirk Lund.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2633: When turning on fine logging, GEODE logs the keystore password in 
> clear text
> 
> 
> Diffs
> -
> 
>   geode-core/src/main/java/org/apache/geode/internal/net/SocketCreator.java 
> 742e7f3e93e595844675d0789b995e4ceb4431ac 
>   
> geode-core/src/main/java/org/apache/geode/internal/util/ArgumentRedactor.java 
> 419f3f976159e601c95a2042bafd96cc9fe9465f 
> 
> 
> Diff: https://reviews.apache.org/r/57431/diff/1/
> 
> 
> Testing
> ---
> 
> precheckin running
> 
> 
> Thanks,
> 
> Kevin Duling
> 
>

Re: A force push happened to geode-native develop!?!

[Anthony Baker]

I believe it is (but would be good to verify).

Anthony

> On Mar 8, 2017, at 1:55 PM, Jared Stewart  wrote:
> 
> +1 to blocking force pushes on shared branches.  It also would seem prudent 
> to block 'git push —delete’ on shared branches if that isn’t already blocked.
> 
>> On Mar 8, 2017, at 1:48 PM, Dan Smith  wrote:
>> 
>> Karen and I just spent a long time tracking down weird git history in her
>> checkout to discover that someone did a force push of the geode-native
>> develop. That's not cool, because it screws over anyone with a copy of the
>> branch and we potentially lost history.
>> 
>> I think we need to do two things.
>> 
>> 1) Block force pushes on any shared branches (develop, master, release-*).
>> If we are in agreement, I'll file a JIRA with INFRA
>> 
>> 2) Figure out what to with geode-native develop. It looks like there have
>> been commits since the force push. Do we keep what is on the branch now, or
>> try to put it back to what it was?
>> 
>> -Dan
>> 
>> 
>> From: jbarr...@apache.org
>> 
>> 4:57 PM (20 hours ago)
>> 
>> to commits
>> Repository: geode-native
>> Updated Branches:
>> refs/heads/develop aff706be2 -> 06e8f39a0 (forced update)
> 

Re: A force push happened to geode-native develop!?!

[Dan Smith]

Yeah, shared branches was kinda of a vague term. I am talking about
develop, master, and release*.

I think in general if you are working on a feature branch with along other
people, you also shouldn't force push that feature branch, but for the
moment the proposal is just to protect develop, master, and release*

I agree with should also block push --delete for develop and master.

-Dan

On Wed, Mar 8, 2017 at 3:04 PM, Jared Stewart  wrote:

> When I say “shared branches”, I’m thinking of develop, master, and
> release-* as mentioned by Dan.
>
>
> > On Mar 8, 2017, at 3:03 PM, Dave Barnes  wrote:
> >
> >> It also would seem prudent to block 'git push —delete’ on shared
> branches
> >
> > Isn't that how we clean up feature branches?
> >
> > On Wed, Mar 8, 2017 at 1:55 PM, Jared Stewart 
> wrote:
> >
> >> +1 to blocking force pushes on shared branches.  It also would seem
> >> prudent to block 'git push —delete’ on shared branches if that isn’t
> >> already blocked.
> >>
> >>> On Mar 8, 2017, at 1:48 PM, Dan Smith  wrote:
> >>>
> >>> Karen and I just spent a long time tracking down weird git history in
> her
> >>> checkout to discover that someone did a force push of the geode-native
> >>> develop. That's not cool, because it screws over anyone with a copy of
> >> the
> >>> branch and we potentially lost history.
> >>>
> >>> I think we need to do two things.
> >>>
> >>> 1) Block force pushes on any shared branches (develop, master,
> >> release-*).
> >>> If we are in agreement, I'll file a JIRA with INFRA
> >>>
> >>> 2) Figure out what to with geode-native develop. It looks like there
> have
> >>> been commits since the force push. Do we keep what is on the branch
> now,
> >> or
> >>> try to put it back to what it was?
> >>>
> >>> -Dan
> >>>
> >>>
> >>> From: jbarr...@apache.org
> >>>
> >>> 4:57 PM (20 hours ago)
> >>>
> >>> to commits
> >>> Repository: geode-native
> >>> Updated Branches:
> >>> refs/heads/develop aff706be2 -> 06e8f39a0 (forced update)
> >>
> >>
>
>

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

[Spring CI]

---
Spring Data GemFire > Nightly-ApacheGeode > #494 was successful (rerun once).
---
This build was rerun by John Blum.
1682 tests in total.

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





--
This message is automatically generated by Atlassian Bamboo

[jira] [Commented] (GEODE-2576) delete the old exported zip on the locator

[Swapnil Bawaskar (JIRA)]

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

Swapnil Bawaskar commented on GEODE-2576:
-

I think we should delete the file as soon as the locator is done sending the 
file to gfsh, rather than deleting periodically.


> delete the old exported zip on the locator
> --
>
> Key: GEODE-2576
> URL: https://issues.apache.org/jira/browse/GEODE-2576
> Project: Geode
>  Issue Type: Sub-task
>  Components: configuration, gfsh
>Reporter: Jinmei Liao
>
> Currently when user is exporting logs over jmx connection, a zip file will be 
> created in the locator's working dir with a unique file name. If user does 
> exports for multiple times, all these zips will be created and we have no 
> mechanism to clean them up unless user go in there to delete them.
> May need to decide whether this is a problem or not. If it is, we need to 
> implement a way to delete these stale zip files periodically.



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

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

[Kevin Duling (JIRA)]

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

Kevin Duling reopened GEODE-2539:
-

Integration test failed as a result of this change.  Backed out until resolved

> 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
>Assignee: Kevin Duling
> Fix For: 1.2.0
>
>
> 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, 2 failed
> :geode-assembly:integrationTest FAILED
> {noformat}

Re: [jira] [Commented] (GEODE-2576) delete the old exported zip on the locator

[Michael Stolz]

Agreed. There is NO value in holding onto it.

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

On Wed, Mar 8, 2017 at 6:34 PM, Swapnil Bawaskar (JIRA) 
wrote:

>
> [ https://issues.apache.org/jira/browse/GEODE-2576?page=
> com.atlassian.jira.plugin.system.issuetabpanels:comment-
> tabpanel&focusedCommentId=15902169#comment-15902169 ]
>
> Swapnil Bawaskar commented on GEODE-2576:
> -
>
> I think we should delete the file as soon as the locator is done sending
> the file to gfsh, rather than deleting periodically.
>
>
> > delete the old exported zip on the locator
> > --
> >
> > Key: GEODE-2576
> > URL: https://issues.apache.org/jira/browse/GEODE-2576
> > Project: Geode
> >  Issue Type: Sub-task
> >  Components: configuration, gfsh
> >Reporter: Jinmei Liao
> >
> > Currently when user is exporting logs over jmx connection, a zip file
> will be created in the locator's working dir with a unique file name. If
> user does exports for multiple times, all these zips will be created and we
> have no mechanism to clean them up unless user go in there to delete them.
> > May need to decide whether this is a problem or not. If it is, we need
> to implement a way to delete these stale zip files periodically.
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.3.15#6346)
>

Re: A force push happened to geode-native develop!?!

[Kevin Duling]

+1. Don't turn to the dark side of the --force.

On Mar 8, 2017 3:12 PM, "Dan Smith"  wrote:

> Yeah, shared branches was kinda of a vague term. I am talking about
> develop, master, and release*.
>
> I think in general if you are working on a feature branch with along other
> people, you also shouldn't force push that feature branch, but for the
> moment the proposal is just to protect develop, master, and release*
>
> I agree with should also block push --delete for develop and master.
>
> -Dan
>
> On Wed, Mar 8, 2017 at 3:04 PM, Jared Stewart  wrote:
>
> > When I say “shared branches”, I’m thinking of develop, master, and
> > release-* as mentioned by Dan.
> >
> >
> > > On Mar 8, 2017, at 3:03 PM, Dave Barnes  wrote:
> > >
> > >> It also would seem prudent to block 'git push —delete’ on shared
> > branches
> > >
> > > Isn't that how we clean up feature branches?
> > >
> > > On Wed, Mar 8, 2017 at 1:55 PM, Jared Stewart 
> > wrote:
> > >
> > >> +1 to blocking force pushes on shared branches.  It also would seem
> > >> prudent to block 'git push —delete’ on shared branches if that isn’t
> > >> already blocked.
> > >>
> > >>> On Mar 8, 2017, at 1:48 PM, Dan Smith  wrote:
> > >>>
> > >>> Karen and I just spent a long time tracking down weird git history in
> > her
> > >>> checkout to discover that someone did a force push of the
> geode-native
> > >>> develop. That's not cool, because it screws over anyone with a copy
> of
> > >> the
> > >>> branch and we potentially lost history.
> > >>>
> > >>> I think we need to do two things.
> > >>>
> > >>> 1) Block force pushes on any shared branches (develop, master,
> > >> release-*).
> > >>> If we are in agreement, I'll file a JIRA with INFRA
> > >>>
> > >>> 2) Figure out what to with geode-native develop. It looks like there
> > have
> > >>> been commits since the force push. Do we keep what is on the branch
> > now,
> > >> or
> > >>> try to put it back to what it was?
> > >>>
> > >>> -Dan
> > >>>
> > >>>
> > >>> From: jbarr...@apache.org
> > >>>
> > >>> 4:57 PM (20 hours ago)
> > >>>
> > >>> to commits
> > >>> Repository: geode-native
> > >>> Updated Branches:
> > >>> refs/heads/develop aff706be2 -> 06e8f39a0 (forced update)
> > >>
> > >>
> >
> >
>

Review Request 57437: GEODE-2594: do not use Attach API or tools.jar by default and deprecate --pid command options

[Kirk Lund]

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

Review request for geode, Jinmei Liao, Jared Stewart, Kevin Duling, Ken Howe, 
and Swapnil Bawaskar.


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


Repository: geode


Description
---

Remove tools.jar from gfsh classpath

Deprecate --pid option for status and stop commands

Remove usage of Attach API from start commands

* rename LauncherLifecycleCommandsTest
* add todo comment to ProcessUtils
* deprecate AttachAPINotFoundException
* remove usage of Attach API from LauncherLifecycleCommands


Diffs
-

  geode-assembly/src/main/dist/bin/gfsh 
309723e9033bb44f25e2f8cbb797abf888735130 
  geode-assembly/src/main/dist/bin/gfsh.bat 
5a401413fd7d58ae753fe50538f76fbced334746 
  
geode-assembly/src/test/java/org/apache/geode/management/internal/cli/commands/LauncherLifecycleCommandsIntegrationTest.java
 1872a8484905b45bed5cf2874e89ab5049c178c2 
  
geode-assembly/src/test/java/org/apache/geode/management/internal/cli/commands/LauncherLifecycleCommandsJUnitTest.java
 947da4243010e06b53a4309374999437669503d0 
  geode-core/src/main/java/org/apache/geode/distributed/AbstractLauncher.java 
64e20f305b8f07298c61421a29888d5eae3dacad 
  geode-core/src/main/java/org/apache/geode/internal/process/ProcessUtils.java 
f15489f757bee3bdc806f90e2ef84b0111c35a93 
  
geode-core/src/main/java/org/apache/geode/lang/AttachAPINotFoundException.java 
576c19e162057dbdf2cec0cd7bb1e83aab3ebb91 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/LauncherLifecycleCommands.java
 e677ba399e0955d495eb42b57bfbce52d652a2a4 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/i18n/CliStrings.java
 7696aa87aee7bd270ca206c9761a91775f7f5f9a 
  
geode-core/src/test/java/org/apache/geode/distributed/AbstractLauncherTest.java 
f487df9c0bae6b133697dafe3705d85b24f0b11b 


Diff: https://reviews.apache.org/r/57437/diff/1/


Testing
---

precheckin in progress


Thanks,

Kirk Lund

[GitHub] geode pull request #419: GEODE-2592 Document Lucene-related gfsh commands

[davebarnes97]

GitHub user davebarnes97 opened a pull request:

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

GEODE-2592 Document Lucene-related gfsh commands



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

$ git pull https://github.com/davebarnes97/geode feature/GEODE-2592

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

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


commit 4494e0ae788f0aa9f15e7f3ab0e4d57b00a2f310
Author: Dave Barnes 
Date:   2017-03-09T00:00:58Z

GEODE-2592 Document Lucene-related gfsh commands




---
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-2592) Document Lucene-related gfsh commands

[ASF GitHub Bot (JIRA)]

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

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

GitHub user davebarnes97 opened a pull request:

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

GEODE-2592 Document Lucene-related gfsh commands



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

$ git pull https://github.com/davebarnes97/geode feature/GEODE-2592

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

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


commit 4494e0ae788f0aa9f15e7f3ab0e4d57b00a2f310
Author: Dave Barnes 
Date:   2017-03-09T00:00:58Z

GEODE-2592 Document Lucene-related gfsh commands




> Document Lucene-related gfsh commands
> -
>
> Key: GEODE-2592
> URL: https://issues.apache.org/jira/browse/GEODE-2592
> Project: Geode
>  Issue Type: New Feature
>  Components: docs
>Reporter: Dave Barnes
>Assignee: Dave Barnes
>
> Add five new Lucene-related gfsh commands to the gfsh command reference pages:
> create lucene index, describe lucene index, destroy lucene index, list lucene 
> indexes, search lucene.



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

[GitHub] geode pull request #420: GEODE-2635: Creating DUnit tests to test eviction i...

[nabarunnag]

GitHub user nabarunnag opened a pull request:

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

GEODE-2635: Creating DUnit tests to test eviction in lucene

* DUnit tests for eviction with local destroy and overflow
* Refactored the integration tests for eviction

@upthewaterspout @jhuynh1 @boglesby @gesterzhou @ladyVader 

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

$ git pull https://github.com/nabarunnag/incubator-geode feature/GEODE-2635

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

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


commit 642634cb1359249cba1d3030f761260dddaf217e
Author: nabarunnag 
Date:   2017-03-09T00:16:52Z

GEODE-2635: Creating DUnit tests to test eviction in lucene

* DUnit tests for eviction with local destroy and overflow
* Refactored the integration tests for eviction




---
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-2635) Create Lucene DUnit tests to check eviction attributes

[ASF GitHub Bot (JIRA)]

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

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

GitHub user nabarunnag opened a pull request:

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

GEODE-2635: Creating DUnit tests to test eviction in lucene

* DUnit tests for eviction with local destroy and overflow
* Refactored the integration tests for eviction

@upthewaterspout @jhuynh1 @boglesby @gesterzhou @ladyVader 

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

$ git pull https://github.com/nabarunnag/incubator-geode feature/GEODE-2635

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

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


commit 642634cb1359249cba1d3030f761260dddaf217e
Author: nabarunnag 
Date:   2017-03-09T00:16:52Z

GEODE-2635: Creating DUnit tests to test eviction in lucene

* DUnit tests for eviction with local destroy and overflow
* Refactored the integration tests for eviction




> Create Lucene DUnit tests to check eviction attributes
> --
>
> Key: GEODE-2635
> URL: https://issues.apache.org/jira/browse/GEODE-2635
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: nabarun
>
> Create LuceneDunit tests which tests eviction with both local destroy and 
> overflow to disk



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

[jira] [Assigned] (GEODE-2599) `start locator` prints `null` in startup dots.

[Kirk Lund (JIRA)]

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

Kirk Lund reassigned GEODE-2599:


Assignee: Kirk Lund

> `start locator` prints `null` in startup dots.
> --
>
> Key: GEODE-2599
> URL: https://issues.apache.org/jira/browse/GEODE-2599
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Affects Versions: 1.2.0
>Reporter: Patrick Rhomberg
>Assignee: Kirk Lund
>Priority: Minor
>  Labels: gfsh
>
> {noformat}
> gfsh>start locator --name=loc1
> Starting a Geode Locator in /Users/prhomberg/workspace/gemfire/open/loc1...
> ..
> null
> .
> Locator in /Users/prhomberg/workspace/gemfire/open/loc1 on 
> 10.118.33.239[10334] as loc1 is currently online.
> Process ID: 41909
> Uptime: 2 seconds
> Geode Version: 0.0.0
> Java Version: 1.8.0_121
> Log File: /Users/prhomberg/workspace/gemfire/open/loc1/loc1.log
> JVM Arguments: -Dgemfire.enable-cluster-configuration=true 
> -Dgemfire.load-cluster-configuration-from-dir=false 
> -Dgemfire.launcher.registerSignalHandlers=true -Djava.awt.headless=true 
> -Dsun.rmi.dgc.server.gcInterval=9223372036854775806
> Class-Path: 
> /Users/prhomberg/workspace/gemfire/open/geode-assembly/build/install/apache-geode/lib/geode-core-0.0.0.jar:/Users/prhomberg/workspace/gemfire/open/geode-assembly/build/install/apache-geode/lib/geode-dependencies.jar
> Successfully connected to: JMX Manager [host=10.118.33.239, port=1099]
> Cluster configuration service is up and running.
> {noformat}



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

[GitHub] geode pull request #420: GEODE-2635: Creating DUnit tests to test eviction i...

[upthewaterspout]

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

https://github.com/apache/geode/pull/420#discussion_r105061375
  
--- Diff: 
geode-lucene/src/test/java/org/apache/geode/cache/lucene/EvictionDUnitTest.java 
---
@@ -0,0 +1,145 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more 
contributor license
+ * agreements. See the NOTICE file distributed with this work for 
additional information regarding
+ * copyright ownership. The ASF licenses this file to You under the Apache 
License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the 
License. You may obtain a
+ * copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software 
distributed under the License
+ * is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF 
ANY KIND, either express
+ * or implied. See the License for the specific language governing 
permissions and limitations under
+ * the License.
+ */
+package org.apache.geode.cache.lucene;
+
+import static 
org.apache.geode.cache.lucene.test.LuceneTestUtilities.INDEX_NAME;
+import static 
org.apache.geode.cache.lucene.test.LuceneTestUtilities.REGION_NAME;
+import static org.junit.Assert.assertEquals;
+import static org.junit.Assert.assertNull;
+import static org.junit.Assert.assertTrue;
+
+import org.apache.geode.cache.Cache;
+import org.apache.geode.cache.Region;
+import org.apache.geode.distributed.internal.DistributionConfig;
+import org.apache.geode.internal.cache.GemFireCacheImpl;
+import org.apache.geode.internal.cache.PartitionedRegion;
+import org.apache.geode.internal.cache.control.HeapMemoryMonitor;
+import org.apache.geode.test.dunit.SerializableRunnableIF;
+import org.apache.geode.test.junit.categories.DistributedTest;
+import org.awaitility.Awaitility;
+import org.junit.Test;
+import org.junit.experimental.categories.Category;
+import org.junit.runner.RunWith;
+
+import java.util.List;
+import java.util.concurrent.TimeUnit;
+import java.util.stream.IntStream;
+import junitparams.JUnitParamsRunner;
+import junitparams.Parameters;
+
+
+@Category(DistributedTest.class)
+@RunWith(JUnitParamsRunner.class)
+public class EvictionDUnitTest extends LuceneQueriesAccessorBase {
+
+  protected final static float INITIAL_EVICTION_HEAP_PERCENTAGE = 50.9f;
+  protected final static float EVICTION_HEAP_PERCENTAGE_FAKE_NOTIFICATION 
= 85.0f;
+  protected final static int TEST_MAX_MEMORY = 100;
+  protected final static int MEMORY_USED_FAKE_NOTIFICATION = 90;
+
+  protected RegionTestableType[] 
getPartitionRedundantOverflowEvictionRegionType() {
+return new RegionTestableType[] 
{RegionTestableType.PARTITION_REDUNDANT_EVICTION_OVERFLOW,
+
RegionTestableType.PARTITION_PERSISTENT_REDUNDANT_EVICTION_OVERFLOW};
+  }
+
+  protected RegionTestableType[] 
getPartitionRedundantLocalDestroyEvictionRegionType() {
+return new RegionTestableType[] 
{RegionTestableType.PARTITION_REDUNDANT_EVICTION_LOCAL_DESTROY};
+  }
+
+  @Test
+  @Parameters(method = 
"getPartitionRedundantLocalDestroyEvictionRegionType")
+  public void 
regionWithEvictionWithLocalDestroyMustNotbeAbleToCreateLuceneIndexes(
+  RegionTestableType regionTestType) {
+SerializableRunnableIF createIndex = () -> {
+  LuceneService luceneService = LuceneServiceProvider.get(getCache());
+  luceneService.createIndex(INDEX_NAME, REGION_NAME, "text");
+};
+
+dataStore1.invoke(() -> {
+  try {
+initDataStore(createIndex, regionTestType);
+  } catch (UnsupportedOperationException e) {
+assertEquals(
+"Lucene indexes on regions with eviction and action local 
destroy are not supported",
+e.getMessage());
+assertNull(getCache().getRegion(REGION_NAME));
+  }
+});
+
+  }
+
+  @Test
+  @Parameters(method = "getPartitionRedundantOverflowEvictionRegionType")
+  public void 
regionsWithEvictionWithOverflowMustBeAbleToCreateLuceneIndexes(
+  RegionTestableType regionTestType) {
+SerializableRunnableIF createIndex = () -> {
+  LuceneService luceneService = LuceneServiceProvider.get(getCache());
+  luceneService.createIndex(INDEX_NAME, REGION_NAME, "text");
+};
+
+dataStore1.invoke(() -> initDataStore(createIndex, regionTestType));
+
+accessor.invoke(() -> initDataStore(createIndex, regionTestType));
+
+accessor.invoke(() -> {
+  Cache cache = getCache();
+  Region region = cache.getRegion(REGION_NAME);
+  IntStream.range(0, NUM_BUCKETS).f

[jira] [Commented] (GEODE-2635) Create Lucene DUnit tests to check eviction attributes

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/geode/pull/420#discussion_r105061375
  
--- Diff: 
geode-lucene/src/test/java/org/apache/geode/cache/lucene/EvictionDUnitTest.java 
---
@@ -0,0 +1,145 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more 
contributor license
+ * agreements. See the NOTICE file distributed with this work for 
additional information regarding
+ * copyright ownership. The ASF licenses this file to You under the Apache 
License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the 
License. You may obtain a
+ * copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software 
distributed under the License
+ * is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF 
ANY KIND, either express
+ * or implied. See the License for the specific language governing 
permissions and limitations under
+ * the License.
+ */
+package org.apache.geode.cache.lucene;
+
+import static 
org.apache.geode.cache.lucene.test.LuceneTestUtilities.INDEX_NAME;
+import static 
org.apache.geode.cache.lucene.test.LuceneTestUtilities.REGION_NAME;
+import static org.junit.Assert.assertEquals;
+import static org.junit.Assert.assertNull;
+import static org.junit.Assert.assertTrue;
+
+import org.apache.geode.cache.Cache;
+import org.apache.geode.cache.Region;
+import org.apache.geode.distributed.internal.DistributionConfig;
+import org.apache.geode.internal.cache.GemFireCacheImpl;
+import org.apache.geode.internal.cache.PartitionedRegion;
+import org.apache.geode.internal.cache.control.HeapMemoryMonitor;
+import org.apache.geode.test.dunit.SerializableRunnableIF;
+import org.apache.geode.test.junit.categories.DistributedTest;
+import org.awaitility.Awaitility;
+import org.junit.Test;
+import org.junit.experimental.categories.Category;
+import org.junit.runner.RunWith;
+
+import java.util.List;
+import java.util.concurrent.TimeUnit;
+import java.util.stream.IntStream;
+import junitparams.JUnitParamsRunner;
+import junitparams.Parameters;
+
+
+@Category(DistributedTest.class)
+@RunWith(JUnitParamsRunner.class)
+public class EvictionDUnitTest extends LuceneQueriesAccessorBase {
+
+  protected final static float INITIAL_EVICTION_HEAP_PERCENTAGE = 50.9f;
+  protected final static float EVICTION_HEAP_PERCENTAGE_FAKE_NOTIFICATION 
= 85.0f;
+  protected final static int TEST_MAX_MEMORY = 100;
+  protected final static int MEMORY_USED_FAKE_NOTIFICATION = 90;
+
+  protected RegionTestableType[] 
getPartitionRedundantOverflowEvictionRegionType() {
+return new RegionTestableType[] 
{RegionTestableType.PARTITION_REDUNDANT_EVICTION_OVERFLOW,
+
RegionTestableType.PARTITION_PERSISTENT_REDUNDANT_EVICTION_OVERFLOW};
+  }
+
+  protected RegionTestableType[] 
getPartitionRedundantLocalDestroyEvictionRegionType() {
+return new RegionTestableType[] 
{RegionTestableType.PARTITION_REDUNDANT_EVICTION_LOCAL_DESTROY};
+  }
+
+  @Test
+  @Parameters(method = 
"getPartitionRedundantLocalDestroyEvictionRegionType")
+  public void 
regionWithEvictionWithLocalDestroyMustNotbeAbleToCreateLuceneIndexes(
+  RegionTestableType regionTestType) {
+SerializableRunnableIF createIndex = () -> {
+  LuceneService luceneService = LuceneServiceProvider.get(getCache());
+  luceneService.createIndex(INDEX_NAME, REGION_NAME, "text");
+};
+
+dataStore1.invoke(() -> {
+  try {
+initDataStore(createIndex, regionTestType);
+  } catch (UnsupportedOperationException e) {
+assertEquals(
+"Lucene indexes on regions with eviction and action local 
destroy are not supported",
+e.getMessage());
+assertNull(getCache().getRegion(REGION_NAME));
+  }
+});
+
+  }
+
+  @Test
+  @Parameters(method = "getPartitionRedundantOverflowEvictionRegionType")
+  public void 
regionsWithEvictionWithOverflowMustBeAbleToCreateLuceneIndexes(
+  RegionTestableType regionTestType) {
+SerializableRunnableIF createIndex = () -> {
+  LuceneService luceneService = LuceneServiceProvider.get(getCache());
+  luceneService.createIndex(INDEX_NAME, REGION_NAME, "text");
+};
+
+dataStore1.invoke(() -> initDataStore(createIndex, regionTestType));
   

[jira] [Created] (GEODE-2638) A GatewaySender fails to start if it attempts to connect to a remote locator that is an unresolvable hostname

[Barry Oglesby (JIRA)]

Barry Oglesby created GEODE-2638:


 Summary: A GatewaySender fails to start if it attempts to connect 
to a remote locator that is an unresolvable hostname
 Key: GEODE-2638
 URL: https://issues.apache.org/jira/browse/GEODE-2638
 Project: Geode
  Issue Type: Bug
  Components: wan
Reporter: Barry Oglesby


A GatewaySender fails to start if it attempts to connect to a remote locator 
that is an unresolvable hostname.

An exception like below is thrown:
{noformat}
[severe 2017/03/08 16:34:14.927 PST ln-1  tid=0x3a] Message dispatch failed due to unexpected 
exception..
org.apache.geode.InternalGemFireException: Failed getting host from name:  
unknown
at 
org.apache.geode.internal.admin.remote.DistributionLocatorId.(DistributionLocatorId.java:132)
at 
org.apache.geode.internal.cache.wan.AbstractRemoteGatewaySender.initProxy(AbstractRemoteGatewaySender.java:104)
at 
org.apache.geode.internal.cache.wan.GatewaySenderEventRemoteDispatcher.initializeConnection(GatewaySenderEventRemoteDispatcher.java:372)
at 
org.apache.geode.internal.cache.wan.GatewaySenderEventRemoteDispatcher.(GatewaySenderEventRemoteDispatcher.java:78)
at 
org.apache.geode.internal.cache.wan.parallel.RemoteParallelGatewaySenderEventProcessor.initializeEventDispatcher(RemoteParallelGatewaySenderEventProcessor.java:74)
at 
org.apache.geode.internal.cache.wan.AbstractGatewaySenderEventProcessor.setRunningStatus(AbstractGatewaySenderEventProcessor.java:1063)
at 
org.apache.geode.internal.cache.wan.AbstractGatewaySenderEventProcessor.run(AbstractGatewaySenderEventProcessor.java:1035)
{noformat}




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

Review Request 57439: GEODE-2576: delete the zip file on locator after it's being streamed to client.

[Jinmei Liao]

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

Review request for geode, Jared Stewart, Kevin Duling, Ken Howe, and Kirk Lund.


Repository: geode


Description
---

GEODE-2576: delete the zip file on locator after it's being streamed to client.

* also modified a couple tests to use the rules more efficiently.


Diffs
-

  
geode-core/src/main/java/org/apache/geode/management/internal/web/controllers/ExportLogController.java
 f3a59340f0d88d8fb1d24e4db2f95c3ffd7c2fa0 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/functions/ExportLogsFunctionIntegrationTest.java
 72c39dc173b2bde2f8a5d6e034baf5d1cd555725 
  
geode-web/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsOverHttpDUnitTest.java
 8c9442a11b08c1e2e66cc7d424388f19642655d8 
  
geode-web/src/test/java/org/apache/geode/management/internal/cli/commands/QueryNamesOverHttpDUnitTest.java
 4ec9c0d35a029af14de511b7ae19688b7e4da0a3 


Diff: https://reviews.apache.org/r/57439/diff/1/


Testing
---

precheckin running


Thanks,

Jinmei Liao

Re: A force push happened to geode-native develop!?!

[Mark Bretl]

+1 For no force push

--Mark

On Wed, Mar 8, 2017 at 3:50 PM, Kevin Duling  wrote:

> +1. Don't turn to the dark side of the --force.
>
> On Mar 8, 2017 3:12 PM, "Dan Smith"  wrote:
>
> > Yeah, shared branches was kinda of a vague term. I am talking about
> > develop, master, and release*.
> >
> > I think in general if you are working on a feature branch with along
> other
> > people, you also shouldn't force push that feature branch, but for the
> > moment the proposal is just to protect develop, master, and release*
> >
> > I agree with should also block push --delete for develop and master.
> >
> > -Dan
> >
> > On Wed, Mar 8, 2017 at 3:04 PM, Jared Stewart 
> wrote:
> >
> > > When I say “shared branches”, I’m thinking of develop, master, and
> > > release-* as mentioned by Dan.
> > >
> > >
> > > > On Mar 8, 2017, at 3:03 PM, Dave Barnes  wrote:
> > > >
> > > >> It also would seem prudent to block 'git push —delete’ on shared
> > > branches
> > > >
> > > > Isn't that how we clean up feature branches?
> > > >
> > > > On Wed, Mar 8, 2017 at 1:55 PM, Jared Stewart 
> > > wrote:
> > > >
> > > >> +1 to blocking force pushes on shared branches.  It also would seem
> > > >> prudent to block 'git push —delete’ on shared branches if that isn’t
> > > >> already blocked.
> > > >>
> > > >>> On Mar 8, 2017, at 1:48 PM, Dan Smith  wrote:
> > > >>>
> > > >>> Karen and I just spent a long time tracking down weird git history
> in
> > > her
> > > >>> checkout to discover that someone did a force push of the
> > geode-native
> > > >>> develop. That's not cool, because it screws over anyone with a copy
> > of
> > > >> the
> > > >>> branch and we potentially lost history.
> > > >>>
> > > >>> I think we need to do two things.
> > > >>>
> > > >>> 1) Block force pushes on any shared branches (develop, master,
> > > >> release-*).
> > > >>> If we are in agreement, I'll file a JIRA with INFRA
> > > >>>
> > > >>> 2) Figure out what to with geode-native develop. It looks like
> there
> > > have
> > > >>> been commits since the force push. Do we keep what is on the branch
> > > now,
> > > >> or
> > > >>> try to put it back to what it was?
> > > >>>
> > > >>> -Dan
> > > >>>
> > > >>>
> > > >>> From: jbarr...@apache.org
> > > >>>
> > > >>> 4:57 PM (20 hours ago)
> > > >>>
> > > >>> to commits
> > > >>> Repository: geode-native
> > > >>> Updated Branches:
> > > >>> refs/heads/develop aff706be2 -> 06e8f39a0 (forced update)
> > > >>
> > > >>
> > >
> > >
> >
>

Re: Review Request 57206: let LuceneResultStruct to be Serializable, then customer does not have to defined their Serializable class to hold result

[xiaojian zhou]

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

(Updated March 9, 2017, 1:20 a.m.)


Review request for geode, Barry Oglesby and Dan Smith.


Changes
---

another option to fix


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


Repository: geode


Description
---

If customer call a lucene query in a function, they need to define their own 
Serializable class to collect results. This has been complained by field 
engineer. 

It will not hurt to let LuceneResultStruct to extend Serializable


Diffs (updated)
-

  
geode-core/src/main/java/org/apache/geode/internal/DataSerializableFixedID.java 
63a95a5 
  
geode-lucene/src/main/java/org/apache/geode/cache/lucene/LuceneResultStruct.java
 5d2184e 
  
geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/LuceneResultStructImpl.java
 6c31025 
  
geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/LuceneServiceImpl.java
 5c908f5 


Diff: https://reviews.apache.org/r/57206/diff/3/

Changes: https://reviews.apache.org/r/57206/diff/2-3/


Testing
---


Thanks,

xiaojian zhou

[jira] [Commented] (GEODE-2595) Change LuceneService.createIndex to use a factory pattern

[ASF GitHub Bot (JIRA)]

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

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

GitHub user upthewaterspout opened a pull request:

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

GEODE-2595: Change LuceneService.createIndex to use a factory

Changing LuceneService.createIndex to createIndexFactory and
using a factory pattern to create the index.

This allows us to introduce new options to the index create without
breaking backwards compatibility in the future.

@ladyVader @nabarunnag @boglesby

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

$ git pull https://github.com/upthewaterspout/incubator-geode 
feature/GEODE-2595

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

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


commit f912be793ff7a73855df903148d4b74dfdc415b9
Author: Dan Smith 
Date:   2017-03-09T01:15:44Z

GEODE-2595: Change LuceneService.createIndex to use a factory

Changing LuceneService.createIndex to createIndexFactory and
using a factory pattern to create the index.

This allows us to introduce new options to the index create without
breaking backwards compatibility in the future.




> Change LuceneService.createIndex to use a factory pattern
> -
>
> Key: GEODE-2595
> URL: https://issues.apache.org/jira/browse/GEODE-2595
> Project: Geode
>  Issue Type: Improvement
>  Components: lucene
>Reporter: Dan Smith
>
> Before we remove the Experimental annotation from the LuceneService, we 
> should change createIndex to use a factory pattern rather than having a 
> single method with parameters to create the index. In other words, the method 
> needs to change from:
> {code}
> luceneService.createIndex(region, index, ...)
> {code}
> to
> {code}
> luceneService.createIndexFactory()
>   .setXXX()
>   .setYYY()
>   .create()
> {code}
> This will allow us to add additional set methods in the future to configure 
> other things like the async event queue batch size, etc.



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

[GitHub] geode pull request #421: GEODE-2595: Change LuceneService.createIndex to use...

[upthewaterspout]

GitHub user upthewaterspout opened a pull request:

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

GEODE-2595: Change LuceneService.createIndex to use a factory

Changing LuceneService.createIndex to createIndexFactory and
using a factory pattern to create the index.

This allows us to introduce new options to the index create without
breaking backwards compatibility in the future.

@ladyVader @nabarunnag @boglesby

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

$ git pull https://github.com/upthewaterspout/incubator-geode 
feature/GEODE-2595

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

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


commit f912be793ff7a73855df903148d4b74dfdc415b9
Author: Dan Smith 
Date:   2017-03-09T01:15:44Z

GEODE-2595: Change LuceneService.createIndex to use a factory

Changing LuceneService.createIndex to createIndexFactory and
using a factory pattern to create the index.

This allows us to introduce new options to the index create without
breaking backwards compatibility in the future.




---
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-2617) LuceneResultStruct should be Serializable

[Diane Hardman (JIRA)]

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

Diane Hardman updated GEODE-2617:
-
Component/s: lucene

> LuceneResultStruct should be Serializable
> -
>
> Key: GEODE-2617
> URL: https://issues.apache.org/jira/browse/GEODE-2617
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: xiaojian zhou
>Assignee: xiaojian zhou
>
> let LuceneResultStruct to be Serializable, then customer does not have to 
> defined their Serializable class to hold result.



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

Re: Review Request 57439: GEODE-2576: delete the zip file on locator after it's being streamed to client.

[Jared Stewart]

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


Ship it!




Ship It!

- Jared Stewart


On March 9, 2017, 12:44 a.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/57439/
> ---
> 
> (Updated March 9, 2017, 12:44 a.m.)
> 
> 
> Review request for geode, Jared Stewart, Kevin Duling, Ken Howe, and Kirk 
> Lund.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2576: delete the zip file on locator after it's being streamed to 
> client.
> 
> * also modified a couple tests to use the rules more efficiently.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/web/controllers/ExportLogController.java
>  f3a59340f0d88d8fb1d24e4db2f95c3ffd7c2fa0 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/functions/ExportLogsFunctionIntegrationTest.java
>  72c39dc173b2bde2f8a5d6e034baf5d1cd555725 
>   
> geode-web/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsOverHttpDUnitTest.java
>  8c9442a11b08c1e2e66cc7d424388f19642655d8 
>   
> geode-web/src/test/java/org/apache/geode/management/internal/cli/commands/QueryNamesOverHttpDUnitTest.java
>  4ec9c0d35a029af14de511b7ae19688b7e4da0a3 
> 
> 
> Diff: https://reviews.apache.org/r/57439/diff/1/
> 
> 
> Testing
> ---
> 
> precheckin running
> 
> 
> Thanks,
> 
> Jinmei Liao
> 
>

Re: [GSoC] Interested in GSoC 2017 ideas

[Hitesh Khamesra]

Hi Kai:
I have couple of ideas..
1. Reliable event processing on Geode.2. New developer friendly apis on Geode. 

Let me know if you some query on this or you have some other idea.
Thanks.Hitesh

  From: Kai Jiang 
 To: dev@geode.apache.org 
Cc: William Markito Oliveira ; Hitesh Khamesra 

 Sent: Tuesday, March 7, 2017 8:05 AM
 Subject: Re: [GSoC] Interested in GSoC 2017 ideas
   
@Anthony,Thanks! I really appreciate for your help and information!
@Hitesh,Nice to e-meet you here! Do you have any idea about GSoC project with 
Geode this year?Looking forward!
Best,Kai
On Tue, Mar 7, 2017 at 7:02 AM, Anthony Baker  wrote:

Hi Kai,

Welcome, and thanks for your interest!  We have one committer interested in 
mentoring so far (Hitesh Khamesra mailto:hitesh...@yahoo.com>>) .  Please feel free to reach out to the 
community for help or questions.  Best of luck to you!

@Committers:  if you want to participate as a mentor in GSoC, now is the time 
to get involved.

Anthony

> On Mar 6, 2017, at 7:30 AM, Kai Jiang  wrote:
>
> Hi All,
>
> I am Kai, a master student majoring in CS from Portland State University,
> highly interested in Big data and Distributed System. I have contributed to
> Apache Spark as a GSoC project last year.
>
> I've been contributing to Geode codebase. Some my Pull Requests are here.(
> https://github.com/apache/geod e/pulls?q=is%3Apr+author%3Avec 
> torijk+is%3Aclosed
> )
> Also, I did some experiments on last year GSoC idea (GEODE-194
>  Geode Spark Connector
> does not support Spark 2.0) on my branch (
> https://github.com/vectorijk/g eode/commits/spark2). I would like to extend
> my work with Geode as a GSoC project this year and look forward to writing
> something meaningful and impactful.
>
> Is there any Geode Committer who's going to sign up as a mentor for GSoC
> this year? Maybe you could tell me about the projects you are going to
> mentor and give me some suggestions about what issues I could fix now to
> get involved. If community has anything else in mind, I am very willing to
> work on some issues before GSoC and get started with something new during
> GSoC.
>
> Looking forward!
>
> Best,
> Kai Jiang
> github.com/vectorijk





   

Build failed in Jenkins: Geode-nightly #770

[Apache Jenkins Server]

See 


Changes:

[dbarnes] GEODE-2591 User guide: Lucene headings should be reflected in 
navigation

[klund] GEODE-2593: add port range to AvailablePortHelper to fix

[huynhja] GEODE-2579: ClassCastException cannot cast CompiledIn to

[klund] GEODE-1198: refactor test with before/after and cleanup use of ports

[gzhou] GEODE-2617: make LuceneResultStruct serializable

[jiliao] GEODE-2267: Enhance server/locator startup rules

[jstewart] GEODE-2621: Reduce time sensitivity of ExportLogsDUnitTest

[klund] GEODE-1198: add todo comment to dubious test

--
[...truncated 118.22 KB...]
Download 
https://repo1.maven.org/maven2/io/springfox/springfox-swagger2/2.6.1/springfox-swagger2-2.6.1.jar
Download 
https://repo1.maven.org/maven2/io/springfox/springfox-swagger-ui/2.6.1/springfox-swagger-ui-2.6.1.jar
Download 
https://repo1.maven.org/maven2/org/springframework/hateoas/spring-hateoas/0.23.0.RELEASE/spring-hateoas-0.23.0.RELEASE.jar
Download 
https://repo1.maven.org/maven2/org/scala-lang/scala-library/2.10.6/scala-library-2.10.6.jar
Download 
https://repo1.maven.org/maven2/org/scala-lang/scala-reflect/2.10.6/scala-reflect-2.10.6.jar
Download 
https://repo1.maven.org/maven2/com/fasterxml/jackson/module/jackson-module-paranamer/2.8.6/jackson-module-paranamer-2.8.6.jar
Download 
https://repo1.maven.org/maven2/io/swagger/swagger-annotations/1.5.10/swagger-annotations-1.5.10.jar
Download 
https://repo1.maven.org/maven2/io/swagger/swagger-models/1.5.10/swagger-models-1.5.10.jar
Download 
https://repo1.maven.org/maven2/io/springfox/springfox-spi/2.6.1/springfox-spi-2.6.1.jar
Download 
https://repo1.maven.org/maven2/io/springfox/springfox-schema/2.6.1/springfox-schema-2.6.1.jar
Download 
https://repo1.maven.org/maven2/io/springfox/springfox-swagger-common/2.6.1/springfox-swagger-common-2.6.1.jar
Download 
https://repo1.maven.org/maven2/io/springfox/springfox-spring-web/2.6.1/springfox-spring-web-2.6.1.jar
Download 
https://repo1.maven.org/maven2/org/springframework/plugin/spring-plugin-core/1.2.0.RELEASE/spring-plugin-core-1.2.0.RELEASE.jar
Download 
https://repo1.maven.org/maven2/org/springframework/plugin/spring-plugin-metadata/1.2.0.RELEASE/spring-plugin-metadata-1.2.0.RELEASE.jar
Download 
https://repo1.maven.org/maven2/org/mapstruct/mapstruct/1.0.0.Final/mapstruct-1.0.0.Final.jar
Download 
https://repo1.maven.org/maven2/com/thoughtworks/paranamer/paranamer/2.8/paranamer-2.8.jar
Download 
https://repo1.maven.org/maven2/io/springfox/springfox-core/2.6.1/springfox-core-2.6.1.jar
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
:geode-web-api:processResources
:geode-web-api:classes
:geode-assembly:docs
:geode-assembly:gfshDepsJar
:geode-common:javadocJar
:geode-common:sourcesJar
:geode-common:signArchives SKIPPED
:geode-core:javadocJar
:geode-core:raJar
:geode-core:jcaJar
:geode-core:sourcesJar
:geode-core:signArchives SKIPPED
:geode-core:webJar
:geode-cq:jar
:geode-cq:javadoc
:geode-cq:javadocJar
:geode-cq:sourcesJar
:geode-cq:signArchives SKIPPED
:geode-json:javadocJar
:geode-json:sourcesJar
:geode-json:signArchives SKIPPED
:geode-lucene:jar
:geode-lucene:javadoc:42:
 warning - Tag @link: reference not found: org.apache.lucene.search
:46:
 warning - Tag @link: reference not found: org.apache.lucene.search
:46:
 warning - Tag @link: reference not found: org.apache.lucene.search

3 warnings
:geode-lucene:javadocJar
:geode-lucene:sourcesJar
:geode-lucene:signArchives SKIPPED
:geode-old-client-support:jar
:geode-old-client-support:javadoc
:geode-old-client-support:javadocJar
:geode-old-client-support:sourcesJar
:geode-old-client-support:signArchives SKIPPED
:geode-pulse:javadoc
:geode-pulse:javadocJar
:geode-pulse:sourcesJar
:geode-pulse:war
:geode-pulse:signArchives SKIPPED
:geode-rebalancer:jar
:geode-rebalancer:javadoc
:geode-rebalancer:javadocJar
:geode-rebalancer:sourcesJar
:geode-rebalancer:signArchives SKIPPED
:geode-wan:jar
:geode-wan:javadoc
:geode-wan:javadocJar
:geode-wan:sourcesJar
:geode-wan:signArchives SKIPPED
:geode-web:javadoc UP-TO-DATE
:geode-web:javadocJar
:geode-web:sourcesJar
:geode-web:war
:geode-web:signArchives SKIPPED
:geode-web-api:javadoc
:geode-web-api:javadocJar
:geode-web-api:sourcesJar
:geode-web-api:war
:geode-web-api:signArchives SKIPPED
:geode-assembly:distTar
:geode-assembly:distZip
:geode-assembly:writeBuildInfo
:geode-assembly:srcDistTar
:geode-assembly:srcDistZip
:geode-assembly:signArchives SKIPPED
:geode-assembly:assemble
:geode-ass

[jira] [Assigned] (GEODE-2622) Fix failures in GMSMembershipManagerJUnitTest caused by upgrading to mockito 2.7.11

[Srikanth Manvi (JIRA)]

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

Srikanth Manvi reassigned GEODE-2622:
-

Assignee: Srikanth Manvi

> Fix failures in GMSMembershipManagerJUnitTest caused by upgrading to mockito 
> 2.7.11
> ---
>
> Key: GEODE-2622
> URL: https://issues.apache.org/jira/browse/GEODE-2622
> Project: Geode
>  Issue Type: Sub-task
>  Components: tests
>Reporter: Kirk Lund
>Assignee: Srikanth Manvi
>
> These tests fail on branch feature/GEODE-2558:
> * GMSMembershipManagerJUnitTest.testDirectChannelSend
> * GMSMembershipManagerJUnitTest.testDirectChannelSendAllRecipients
> * 
> GMSMembershipManagerJUnitTest.testDirectChannelSendFailureDueToForcedDisconnect
> * GMSMembershipManagerJUnitTest.testDirectChannelSendFailureToOneRecipient



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

Re: A force push happened to geode-native develop!?!

[Nitin Lamba]

+1 for no force push on shared branches.

On Wed, Mar 8, 2017 at 4:59 PM, Mark Bretl  wrote:

> +1 For no force push
>
> --Mark
>
> On Wed, Mar 8, 2017 at 3:50 PM, Kevin Duling  wrote:
>
> > +1. Don't turn to the dark side of the --force.
> >
> > On Mar 8, 2017 3:12 PM, "Dan Smith"  wrote:
> >
> > > Yeah, shared branches was kinda of a vague term. I am talking about
> > > develop, master, and release*.
> > >
> > > I think in general if you are working on a feature branch with along
> > other
> > > people, you also shouldn't force push that feature branch, but for the
> > > moment the proposal is just to protect develop, master, and release*
> > >
> > > I agree with should also block push --delete for develop and master.
> > >
> > > -Dan
> > >
> > > On Wed, Mar 8, 2017 at 3:04 PM, Jared Stewart 
> > wrote:
> > >
> > > > When I say “shared branches”, I’m thinking of develop, master, and
> > > > release-* as mentioned by Dan.
> > > >
> > > >
> > > > > On Mar 8, 2017, at 3:03 PM, Dave Barnes 
> wrote:
> > > > >
> > > > >> It also would seem prudent to block 'git push —delete’ on shared
> > > > branches
> > > > >
> > > > > Isn't that how we clean up feature branches?
> > > > >
> > > > > On Wed, Mar 8, 2017 at 1:55 PM, Jared Stewart  >
> > > > wrote:
> > > > >
> > > > >> +1 to blocking force pushes on shared branches.  It also would
> seem
> > > > >> prudent to block 'git push —delete’ on shared branches if that
> isn’t
> > > > >> already blocked.
> > > > >>
> > > > >>> On Mar 8, 2017, at 1:48 PM, Dan Smith  wrote:
> > > > >>>
> > > > >>> Karen and I just spent a long time tracking down weird git
> history
> > in
> > > > her
> > > > >>> checkout to discover that someone did a force push of the
> > > geode-native
> > > > >>> develop. That's not cool, because it screws over anyone with a
> copy
> > > of
> > > > >> the
> > > > >>> branch and we potentially lost history.
> > > > >>>
> > > > >>> I think we need to do two things.
> > > > >>>
> > > > >>> 1) Block force pushes on any shared branches (develop, master,
> > > > >> release-*).
> > > > >>> If we are in agreement, I'll file a JIRA with INFRA
> > > > >>>
> > > > >>> 2) Figure out what to with geode-native develop. It looks like
> > there
> > > > have
> > > > >>> been commits since the force push. Do we keep what is on the
> branch
> > > > now,
> > > > >> or
> > > > >>> try to put it back to what it was?
> > > > >>>
> > > > >>> -Dan
> > > > >>>
> > > > >>>
> > > > >>> From: jbarr...@apache.org
> > > > >>>
> > > > >>> 4:57 PM (20 hours ago)
> > > > >>>
> > > > >>> to commits
> > > > >>> Repository: geode-native
> > > > >>> Updated Branches:
> > > > >>> refs/heads/develop aff706be2 -> 06e8f39a0 (forced update)
> > > > >>
> > > > >>
> > > >
> > > >
> > >
> >
>