[jira] [Commented] (GEODE-2670) pulse with integrated security has authentication and authorization issues

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2670:


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

GEODE-2670: fixing pulse authentication/authorization issues


> pulse with integrated security has authentication and authorization issues
> --
>
> Key: GEODE-2670
> URL: https://issues.apache.org/jira/browse/GEODE-2670
> Project: Geode
>  Issue Type: Bug
>Reporter: Jinmei Liao
>Assignee: Jinmei Liao
>
> Steps to reproduce:
> 1) in gfsh, start up a locator with a security manager
> 2) in the browser, try to connect to pulse: http://localhost:7070/pulse
> 3) when presented a login page, try a invalid username/password.
> 4) when getting "incorrect password" hint, use the same username, try using 
> the correct password for that user. It would still say "incorrect password".
> Also, repeat above step 1 and 2, 
> 3), use a correct username and password that only have cluster:read previlage.
> 4) try to access the dataBrowser.html, expect to get denied access, but is 
> still able to access. 



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

Review Request 57729: GEODE-2634: use log4j levels for auto-completion

[Jinmei Liao]

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

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


Repository: geode


Description
---

* change the auto complete to use log4j levels.
* be able to handle both log4j levels and logwriter levels in the commands
* add validation of log level whenever possible for these commands
* Move the conversion between the two to a LogLevel class and add unit tests


Diffs
-

  geode-core/src/main/java/org/apache/geode/LogWriter.java 
242433fb0bd093df1ebbccce388d4b10a510f391 
  
geode-core/src/main/java/org/apache/geode/admin/internal/DistributedSystemConfigImpl.java
 a89d3904fc999e8a956a06de02b73411987540ee 
  
geode-core/src/main/java/org/apache/geode/distributed/internal/AbstractDistributionConfig.java
 decb61d45b7854005b9c5ab554c4e8ead82dcfd9 
  geode-core/src/main/java/org/apache/geode/i18n/LogWriterI18n.java 
b9a4df3068f0a3474d9125743e9da0b44e981a5f 
  
geode-core/src/main/java/org/apache/geode/internal/admin/remote/RemoteAlert.java
 1783e90ecbe2315b8aa496c44cd9fd59e9eb71ba 
  geode-core/src/main/java/org/apache/geode/internal/logging/GemFireLevel.java 
0e1dc6ecd97e6132a29044ce29d68769de527336 
  geode-core/src/main/java/org/apache/geode/internal/logging/LogWriterImpl.java 
57f0a5cfaf4f975c68be2cc6a1850d5da843259b 
  
geode-core/src/main/java/org/apache/geode/internal/logging/log4j/LogLevel.java 
PRE-CREATION 
  
geode-core/src/main/java/org/apache/geode/internal/logging/log4j/LogWriterAppender.java
 031a3068d4e188be9f9b7a802f26927f3cacd3f7 
  
geode-core/src/main/java/org/apache/geode/internal/logging/log4j/LogWriterLogger.java
 f56599b5490d2dbbacd30a121d135891c67460a4 
  
geode-core/src/main/java/org/apache/geode/management/internal/MemberMessenger.java
 25366f9733305e15a65c24c2f24843b54e32c1dd 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ConfigCommands.java
 8c633828f2bb1e110cad98d016e6bf68f866f5e2 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ExportLogCommand.java
 678fdaf89547326c3743093edea35a264809e64d 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/LauncherLifecycleCommands.java
 3ad93ce3b63730f699ae8b7820f277221342adab 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/MiscellaneousCommands.java
 1fc60271d70982f83fd078ea36a61bfcedb0c5cc 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/converters/LogLevelConverter.java
 39a110c679c43ff192aedcd73a6c68951efffaed 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/ChangeLogLevelFunction.java
 99f37cc8d2d3941e818eaf1a10b9d888f0e3b342 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/ExportLogsFunction.java
 62026fb749fe220c1dfe16ea2255f8ebfe5958d1 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/util/LogLevelExtractor.java
 bbeb5c75a73f3749e7a4f62d76533b847f9ce317 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/util/ReadWriteFile.java
 958ed0ec98bb0e3cd3656f914ffe03b16b38e582 
  
geode-core/src/test/java/org/apache/geode/distributed/internal/DistributionConfigJUnitTest.java
 080136055feb304ebe6bfe28a0da72e67dfde21f 
  
geode-core/src/test/java/org/apache/geode/internal/logging/log4j/LogLevelTest.java
 PRE-CREATION 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsInterceptorJUnitTest.java
 97ed686dcd5a159613f978a4311a44b72b30fefd 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/LogLevelInterceptorTest.java
 PRE-CREATION 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/converters/LogLevelConverterTest.java
 PRE-CREATION 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/functions/ExportLogsFunctionIntegrationTest.java
 cdc57667d5bb06ae904fb04b6b3919a7e879bc7e 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/util/LogLevelExtractorTest.java
 fd7d68bfd2a26d11f3f971bb089476105e46 
  
geode-web/src/test/java/org/apache/geode/management/internal/cli/commands/CommandOverHttpDUnitTest.java
 5f4cd74b8af81ae3bbeff04d6ce44a5c4ac9ec59 


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


Testing
---

precheckin running


Thanks,

Jinmei Liao

[jira] [Commented] (GEODE-2674) Lucene index is out of sync with data region due to retried event

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2674:


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

GEODE-2674 Use null instead of "" for a null value in the queue.


> Lucene index is out of sync with data region due to retried event
> -
>
> Key: GEODE-2674
> URL: https://issues.apache.org/jira/browse/GEODE-2674
> Project: Geode
>  Issue Type: Bug
>Reporter: Dan Smith
>Assignee: Dan Smith
> Fix For: 1.2.0
>
>
> We're seeing issues where the data in the lucene index does not match the 
> data in a region. Here's what I see happening
> # An accessor starts doing a put
> # The put goes to the current primary
> # Primary distributes the put to the secondary
> # Primary closes it's cache
> # New primary does a destroy on the same entry
> # The accessor retries the put because the old primary closed the cache
> # The retried put is added to the queue, after the destroy. But it is not 
> added to the region, because the region detects that it is a retry.
> # The lucene index applies the put. Now there is an extra entry in the index 
> that is not in the region.



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

[jira] [Updated] (GEODE-2681) Gfsh show missing-disk-stores command hangs when server is waiting for disk stores

[Jason Huynh (JIRA)]

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

Jason Huynh updated GEODE-2681:
---
Component/s: (was: core)
 persistence

> Gfsh show missing-disk-stores command hangs when server is waiting for disk 
> stores
> --
>
> Key: GEODE-2681
> URL: https://issues.apache.org/jira/browse/GEODE-2681
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh, persistence
>Affects Versions: 1.1.0
>Reporter: Jason Huynh
> Attachments: cache.xml, oplogs1.tar.gz
>
>
> Similar to GEODE-2680:
> When starting up a server with persistent files, the server waits for the 
> other offline members as expected.  
> When trying to show missing disk stores in a different gfsh process, this 
> command also hangs.  It is expected that this process should not be hung
> Attached is a cache xml file and oplogs to reproduce the file.
> Steps to reproduce:
> Configuration:
> 1.) Edit the cache.xml file to point to the appropriate disk store location
> Commands:
> 1.) start locator —-name=locator1
> 2.) start server --name=server1  -—cache-xml-file=cache.xml
> Attempt to start a separate gfsh process and run the following commands:
> 1.) connect
> 2.) show missing-disk-stores



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

[jira] [Updated] (GEODE-2680) Gfsh start server command hangs while waiting for offline members

[Jason Huynh (JIRA)]

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

Jason Huynh updated GEODE-2680:
---
Component/s: (was: core)
 persistence

> Gfsh start server command hangs while waiting for offline members
> -
>
> Key: GEODE-2680
> URL: https://issues.apache.org/jira/browse/GEODE-2680
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh, persistence
>Affects Versions: 1.1.0
>Reporter: Jason Huynh
> Attachments: cache.xml, oplogs1.tar.gz
>
>
> When starting up a server with persistent files, the server waits for the 
> other offline members as expected.  However the gfsh command seems to not 
> abort and instead is “stuck.”  Gfsh should complete and allow the user/admin 
> to continue administering commands to revoke members etc.
> Attached is a cache xml file and oplogs to reproduce the file.
> Steps to reproduce:
> Configuration:
> 1.) Edit the cache.xml file to point to the appropriate disk store location
> Commands:
> 1.) start locator —-name=locator1
> 2.) start server --name=server1  -—cache-xml-file=cache.xml
> Now the process is stuck.  In my run the locator eventually shuts itself down 
> too...



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

[jira] [Updated] (GEODE-2682) Compaction with async disk writes may resurrect removed entries

[Jason Huynh (JIRA)]

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

Jason Huynh updated GEODE-2682:
---
Component/s: (was: core)
 persistence

> Compaction with async disk writes may resurrect removed entries
> ---
>
> Key: GEODE-2682
> URL: https://issues.apache.org/jira/browse/GEODE-2682
> Project: Geode
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 1.0.0-incubating, 1.1.0
>Reporter: Jason Huynh
> Attachments: cache.xml, oplogs.tar.gz
>
>
> This can occur for persistent async event queues and for regions when 
> concurrency checks are disabled.
> Currently->
> 1.) When rolling a crf we create a krf that is based on the current “live” 
> region
> 2.) If removes are being done at the same time, the krf will reflect the 
> current state, where the keys are not part of the krf file
> 3.) Due to the async disk write, the drf has yet to be updated.
> 4.) If the cluster gets shut down before the drf is written to.  This can 
> lead to the following scenarios:
>  * (No issue) the user recovers with the existing krf/drf/crf files.  This 
> works just fine as the krf has reflected the change
>  * (Problem!) If the user compacts and then recovers, the removed entries are 
> now resurrected and appear in the region due to the way compaction operates.  
> It ignores the krf and works on a the existing crf/drf files.  Because the 
> drf does not reflect removed events, the events are rolled forward from the 
> crf.
> Attached is a set oplogs for a single node prior to compaction and a 
> cache.xml (need to fill in the correct location for the diskstore directory) 
> Recovering from this set of oplogs recovers 0 entries for the async event 
> queues.
> If you run offline compaction on the oplogs and recover, there are now 
> entries in the async event queues.



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

[jira] [Resolved] (GEODE-2643) Combine chunk and file region into a single region

[Jason Huynh (JIRA)]

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

Jason Huynh resolved GEODE-2643.

Resolution: Fixed

> Combine chunk and file region into a single region
> --
>
> Key: GEODE-2643
> URL: https://issues.apache.org/jira/browse/GEODE-2643
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Affects Versions: 1.0.0-incubating
>Reporter: Jason Huynh
>Assignee: Jason Huynh
>
> When recovering the chunk and file region from a back up, it is possible that 
> we end up recovering buckets from different sources.  This possibly leads to 
> missing chunks or extra files, which causes a Corrupt Index Exception to be 
> thrown.



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

[jira] [Updated] (GEODE-2643) Combine chunk and file region into a single region

[Jason Huynh (JIRA)]

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

Jason Huynh updated GEODE-2643:
---
Fix Version/s: 1.2.0

> Combine chunk and file region into a single region
> --
>
> Key: GEODE-2643
> URL: https://issues.apache.org/jira/browse/GEODE-2643
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Affects Versions: 1.0.0-incubating
>Reporter: Jason Huynh
>Assignee: Jason Huynh
> Fix For: 1.2.0
>
>
> When recovering the chunk and file region from a back up, it is possible that 
> we end up recovering buckets from different sources.  This possibly leads to 
> missing chunks or extra files, which causes a Corrupt Index Exception to be 
> thrown.



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

[jira] [Updated] (GEODE-2643) Combine chunk and file region into a single region

[Jason Huynh (JIRA)]

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

Jason Huynh updated GEODE-2643:
---
Affects Version/s: 1.0.0-incubating

> Combine chunk and file region into a single region
> --
>
> Key: GEODE-2643
> URL: https://issues.apache.org/jira/browse/GEODE-2643
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Affects Versions: 1.0.0-incubating
>Reporter: Jason Huynh
>Assignee: Jason Huynh
> Fix For: 1.2.0
>
>
> When recovering the chunk and file region from a back up, it is possible that 
> we end up recovering buckets from different sources.  This possibly leads to 
> missing chunks or extra files, which causes a Corrupt Index Exception to be 
> thrown.



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

[jira] [Created] (GEODE-2684) org.apache.geode.internal.tcp.Connection & ConnectionTable cleanup

[Bruce Schuchardt (JIRA)]

Bruce Schuchardt created GEODE-2684:
---

 Summary: org.apache.geode.internal.tcp.Connection & 
ConnectionTable cleanup
 Key: GEODE-2684
 URL: https://issues.apache.org/jira/browse/GEODE-2684
 Project: Geode
  Issue Type: Bug
  Components: membership
Reporter: Bruce Schuchardt


These classes contain a lot of commented-out code, poorly named methods and 
incorrect calculations that need to be cleaned up.  For instance, Connection 
contains this:

short aShort = -1;
bytes[x] = (byte)(aShort & 0xff / 0x100);
bytes[x+1] = (byte)(aShort & 0xff);

which is incorrect and results in bytes[x] being zero when the intent is for it 
to be 255.



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

[jira] [Updated] (GEODE-2649) ExportLogsDUnitTest.testExportWithStartAndEndDateTimeFiltering fails with AssertionError

[Jared Stewart (JIRA)]

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

Jared Stewart updated GEODE-2649:
-
Labels: CI  (was: )

> ExportLogsDUnitTest.testExportWithStartAndEndDateTimeFiltering fails with 
> AssertionError
> 
>
> Key: GEODE-2649
> URL: https://issues.apache.org/jira/browse/GEODE-2649
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh, tests
>Reporter: Kirk Lund
>Assignee: Jared Stewart
>  Labels: CI
>
> {noformat}
> org.apache.geode.management.internal.cli.commands.ExportLogsDUnitTest > 
> testExportWithStartAndEndDateTimeFiltering FAILED
> java.lang.AssertionError:
> Expected size:<3> but was:<2> in:
> <[/tmp/junit8723178147444223944/unzippedLogs/server-1,
> /tmp/junit8723178147444223944/unzippedLogs/server-2]>
> at 
> org.apache.geode.management.internal.cli.commands.ExportLogsDUnitTest.verifyZipFileContents(ExportLogsDUnitTest.java:225)
> at 
> org.apache.geode.management.internal.cli.commands.ExportLogsDUnitTest.testExportWithStartAndEndDateTimeFiltering(ExportLogsDUnitTest.java:155)
> 303 tests completed, 1 failed, 8 skipped
> {noformat}



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

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

[Jared Stewart (JIRA)]

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

Jared Stewart resolved GEODE-2621.
--
Resolution: Duplicate

> 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] [Resolved] (GEODE-2677) As a Developer I can run queryperf OQL performance tests with offHeap

[Fred Krone (JIRA)]

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

Fred Krone resolved GEODE-2677.
---
Resolution: Duplicate

> As a Developer I can run queryperf OQL performance  tests with offHeap
> --
>
> Key: GEODE-2677
> URL: https://issues.apache.org/jira/browse/GEODE-2677
> Project: Geode
>  Issue Type: Improvement
>  Components: offheap
>Reporter: Fred Krone
>
> Enable running OQL performance regression tests with offheap.
> Constraints:
> The test will be limited to the resource availability (Currently we have 
> 25 m/cs with 300 GB max memory).
> The test needs to aware of the memory consumptions when the region is 
> configured with heap and offheap (keys, region entries, etc).
> Acceptance:
> OQL performance tests enabled for offheap.



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

[jira] [Updated] (GEODE-2676) RegionMBean statistics wrong on partitioned regions

[Darrel Schneider (JIRA)]

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

Darrel Schneider updated GEODE-2676:

Description: 
RegionMBean attributes hitCount, hitRatio, missCount, lastAccessedTime, and 
lastModifiedTime will always be 0 for an mbean that represents an partitioned 
region.

The gettors for these methods may call getStatistics() which on a PR always 
throws UnsupportedOperationException?. So this exception might even get exposed 
to customers.

The initialization of RegionMBeanBridge calls getStatisticsEnabled() which 
returns true on a PartitionedRegion. This does have meaning on a PR but it does 
not mean that getStatistics() is a supported operation. On a PR setting 
statistics-enabled causes each region-entry to also keep track of its last 
access time.
It is true that if getStatisticsEnabled() is false then you should not call 
getStatistics. But the opposite is not true. Since we currently have regions 
that do not support getStatistics(), the code in RegionMBeanBridge should catch 
UnsupportedOperationException and handle it. I would suggest that the 
constructor be changed that initializes the "isStatisticsEnabled" field. 
Instead of only calling getStatisticsEnabled() it should also call 
getStatistics(). Something like this:
{noformat}
{
  boolean useGetStatistics = regAttrs.getStatisticsEnabled();
  if (useGetStatistics) {
try {
  region.getStatistics();
} catch (UnsupportedOperationException ex) {
  useGetStatistics = false;
}
  }
  this.isStatisticsEnabled = useGetStatistics;
}
{noformat}
That way in a future release if PRs are changed to support getStatistics this 
code will start calling it without having a direct dependency on the 
implementation of PartitionedRegion.

Another ticket will be filed requesting that getStatistics to become a 
supported operation on PRs. 

  was:
RegionMBean attributes hitCount, hitRatio, missCount, lastAccessedTime, and 
lastModifiedTime will always be 0 for an mbean that represents an partitioned 
region.

The gettors for these methods may call getStatistics() which on a PR always 
throws UnsupportedOperationException?. So this exception might even get exposed 
to customers.

The initialization of RegionMBeanBridge calls getStatisticsEnabled() which an 
return true on a pr (seems really bad that this can return true yet 
getStatistics always throws).

See Trac ticket: https://svn.gemstone.com/trac/gemfire/ticket/46715


> RegionMBean statistics wrong on partitioned regions
> ---
>
> Key: GEODE-2676
> URL: https://issues.apache.org/jira/browse/GEODE-2676
> Project: Geode
>  Issue Type: Bug
>Reporter: Fred Krone
>Priority: Minor
>  Labels: jmx
>
> RegionMBean attributes hitCount, hitRatio, missCount, lastAccessedTime, and 
> lastModifiedTime will always be 0 for an mbean that represents an partitioned 
> region.
> The gettors for these methods may call getStatistics() which on a PR always 
> throws UnsupportedOperationException?. So this exception might even get 
> exposed to customers.
> The initialization of RegionMBeanBridge calls getStatisticsEnabled() which 
> returns true on a PartitionedRegion. This does have meaning on a PR but it 
> does not mean that getStatistics() is a supported operation. On a PR setting 
> statistics-enabled causes each region-entry to also keep track of its last 
> access time.
> It is true that if getStatisticsEnabled() is false then you should not call 
> getStatistics. But the opposite is not true. Since we currently have regions 
> that do not support getStatistics(), the code in RegionMBeanBridge should 
> catch UnsupportedOperationException and handle it. I would suggest that the 
> constructor be changed that initializes the "isStatisticsEnabled" field. 
> Instead of only calling getStatisticsEnabled() it should also call 
> getStatistics(). Something like this:
> {noformat}
> {
>   boolean useGetStatistics = regAttrs.getStatisticsEnabled();
>   if (useGetStatistics) {
> try {
>   region.getStatistics();
> } catch (UnsupportedOperationException ex) {
>   useGetStatistics = false;
> }
>   }
>   this.isStatisticsEnabled = useGetStatistics;
> }
> {noformat}
> That way in a future release if PRs are changed to support getStatistics this 
> code will start calling it without having a direct dependency on the 
> implementation of PartitionedRegion.
> Another ticket will be filed requesting that getStatistics to become a 
> supported operation on PRs. 



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

[jira] [Updated] (GEODE-2676) RegionMBean statistics wrong on partitioned regions

[Darrel Schneider (JIRA)]

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

Darrel Schneider updated GEODE-2676:

Priority: Minor  (was: Major)

> RegionMBean statistics wrong on partitioned regions
> ---
>
> Key: GEODE-2676
> URL: https://issues.apache.org/jira/browse/GEODE-2676
> Project: Geode
>  Issue Type: Bug
>Reporter: Fred Krone
>Priority: Minor
>  Labels: jmx
>
> RegionMBean attributes hitCount, hitRatio, missCount, lastAccessedTime, and 
> lastModifiedTime will always be 0 for an mbean that represents an partitioned 
> region.
> The gettors for these methods may call getStatistics() which on a PR always 
> throws UnsupportedOperationException?. So this exception might even get 
> exposed to customers.
> The initialization of RegionMBeanBridge calls getStatisticsEnabled() which an 
> return true on a pr (seems really bad that this can return true yet 
> getStatistics always throws).
> See Trac ticket: https://svn.gemstone.com/trac/gemfire/ticket/46715



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

[jira] [Updated] (GEODE-2676) RegionMBean statistics wrong on partitioned regions

[Darrel Schneider (JIRA)]

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

Darrel Schneider updated GEODE-2676:

Description: 
RegionMBean attributes hitCount, hitRatio, missCount, lastAccessedTime, and 
lastModifiedTime will always be 0 for an mbean that represents an partitioned 
region.

The gettors for these methods may call getStatistics() which on a PR always 
throws UnsupportedOperationException. So this exception might even get exposed 
to customers.

The initialization of RegionMBeanBridge calls getStatisticsEnabled() which 
returns true on a PartitionedRegion. This does have meaning on a PR but it does 
not mean that getStatistics() is a supported operation. On a PR setting 
statistics-enabled causes each region-entry to also keep track of its last 
access time.
It is true that if getStatisticsEnabled() is false then you should not call 
getStatistics. But the opposite is not true. Since we currently have regions 
that do not support getStatistics(), the code in RegionMBeanBridge should catch 
UnsupportedOperationException and handle it. I would suggest that the 
constructor be changed that initializes the "isStatisticsEnabled" field. 
Instead of only calling getStatisticsEnabled() it should also call 
getStatistics(). Something like this:
{noformat}
{
  boolean useGetStatistics = regAttrs.getStatisticsEnabled();
  if (useGetStatistics) {
try {
  region.getStatistics();
} catch (UnsupportedOperationException ex) {
  useGetStatistics = false;
}
  }
  this.isStatisticsEnabled = useGetStatistics;
}
{noformat}
That way in a future release if PRs are changed to support getStatistics this 
code will start calling it without having a direct dependency on the 
implementation of PartitionedRegion.

Another ticket will be filed requesting that getStatistics to become a 
supported operation on PRs. 

  was:
RegionMBean attributes hitCount, hitRatio, missCount, lastAccessedTime, and 
lastModifiedTime will always be 0 for an mbean that represents an partitioned 
region.

The gettors for these methods may call getStatistics() which on a PR always 
throws UnsupportedOperationException?. So this exception might even get exposed 
to customers.

The initialization of RegionMBeanBridge calls getStatisticsEnabled() which 
returns true on a PartitionedRegion. This does have meaning on a PR but it does 
not mean that getStatistics() is a supported operation. On a PR setting 
statistics-enabled causes each region-entry to also keep track of its last 
access time.
It is true that if getStatisticsEnabled() is false then you should not call 
getStatistics. But the opposite is not true. Since we currently have regions 
that do not support getStatistics(), the code in RegionMBeanBridge should catch 
UnsupportedOperationException and handle it. I would suggest that the 
constructor be changed that initializes the "isStatisticsEnabled" field. 
Instead of only calling getStatisticsEnabled() it should also call 
getStatistics(). Something like this:
{noformat}
{
  boolean useGetStatistics = regAttrs.getStatisticsEnabled();
  if (useGetStatistics) {
try {
  region.getStatistics();
} catch (UnsupportedOperationException ex) {
  useGetStatistics = false;
}
  }
  this.isStatisticsEnabled = useGetStatistics;
}
{noformat}
That way in a future release if PRs are changed to support getStatistics this 
code will start calling it without having a direct dependency on the 
implementation of PartitionedRegion.

Another ticket will be filed requesting that getStatistics to become a 
supported operation on PRs. 


> RegionMBean statistics wrong on partitioned regions
> ---
>
> Key: GEODE-2676
> URL: https://issues.apache.org/jira/browse/GEODE-2676
> Project: Geode
>  Issue Type: Bug
>Reporter: Fred Krone
>Priority: Minor
>  Labels: jmx
>
> RegionMBean attributes hitCount, hitRatio, missCount, lastAccessedTime, and 
> lastModifiedTime will always be 0 for an mbean that represents an partitioned 
> region.
> The gettors for these methods may call getStatistics() which on a PR always 
> throws UnsupportedOperationException. So this exception might even get 
> exposed to customers.
> The initialization of RegionMBeanBridge calls getStatisticsEnabled() which 
> returns true on a PartitionedRegion. This does have meaning on a PR but it 
> does not mean that getStatistics() is a supported operation. On a PR setting 
> statistics-enabled causes each region-entry to also keep track of its last 
> access time.
> It is true that if getStatisticsEnabled() is false then you should not call 
> getStatistics. But the opposite is not true. Since we currently have regions 
> that do not support getStatistics

[jira] [Resolved] (GEODE-2670) pulse with integrated security has authentication and authorization issues

[Jinmei Liao (JIRA)]

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

Jinmei Liao resolved GEODE-2670.

   Resolution: Fixed
Fix Version/s: 1.2.0

> pulse with integrated security has authentication and authorization issues
> --
>
> Key: GEODE-2670
> URL: https://issues.apache.org/jira/browse/GEODE-2670
> Project: Geode
>  Issue Type: Bug
>Reporter: Jinmei Liao
>Assignee: Jinmei Liao
> Fix For: 1.2.0
>
>
> Steps to reproduce:
> 1) in gfsh, start up a locator with a security manager
> 2) in the browser, try to connect to pulse: http://localhost:7070/pulse
> 3) when presented a login page, try a invalid username/password.
> 4) when getting "incorrect password" hint, use the same username, try using 
> the correct password for that user. It would still say "incorrect password".
> Also, repeat above step 1 and 2, 
> 3), use a correct username and password that only have cluster:read previlage.
> 4) try to access the dataBrowser.html, expect to get denied access, but is 
> still able to access. 



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

Re: Geode log levels vs. log4j log levels

[Anilkumar Gingade]

Thats a good idea...We need to make sure, if there are any internal scripts
that are dependent on the log level gets changed and document (and
highlight) the behavior so that if customers have their scripts, alert
notifications; they modify those...

-Anil.


On Thu, Mar 16, 2017 at 7:50 PM, Jinmei Liao  wrote:

> Looks like our log files in the end, still print out the geode log levels
> like "fine" for "debug", "error" for "fatal". This is because when
> developer wrote
> "logger.debug("message")" in their code, the appender we used will
> internally convert that log message to print out "fine" instead of
> "debug".  So even though we use log4J internally, on the outside, users
> still sees the geode custom levels in the log file.
>
> Should we go ahead and change the log file to the regular log levels and
> work towards getting rid of a log of our log* code?
>
> On Thu, Mar 16, 2017 at 2:31 PM, Darrel Schneider 
> wrote:
>
> > Since we have trace for finer and finest I think all is well.
> >
> > On Thu, Mar 16, 2017 at 1:38 PM, Kirk Lund  wrote:
> >
> > > That's correct. I flipped mine around half way down the list. I love to
> > > delete the old LogWriter log levels to eliminate this confusion...
> > >
> > >
> > > On Thu, Mar 16, 2017 at 1:12 PM, Jinmei Liao 
> wrote:
> > >
> > > > I believe this is the mapping:
> > > >
> > > > LogWriter Log4J2
> > > > ---
> > > > SEVERE= FATAL
> > > > ERROR = ERROR
> > > > WARNING = WARN
> > > > INFO, CONFIG  = INFO
> > > > FINE  = DEBUG
> > > > FINER, FINEST = TRACE
> > > >
> > > > We do have a lot of code that still uses the LogWriter.
> > > >
> > > > On Thu, Mar 16, 2017 at 10:29 AM, Kirk Lund 
> wrote:
> > > >
> > > > > Here's the equivalent log levels between LogWriter levels and
> Log4J2
> > > > levels
> > > > >
> > > > > LogWriter   Log4J2
> > > > > 
> > > > > SEVERE= FATAL
> > > > > ERROR = ERROR
> > > > > WARN  = WARNING
> > > > > INFO  = INFO, CONFIG
> > > > > DEBUG = FINE
> > > > > TRACE = FINER, FINEST
> > > > >
> > > > > On Thu, Mar 16, 2017 at 10:08 AM, Darrel Schneider <
> > > > dschnei...@pivotal.io>
> > > > > wrote:
> > > > >
> > > > > > My understanding is the geode fine, finer, finest all map to
> log4j
> > > > debug.
> > > > > > If we get rid of the geode levels would all three fine* levels be
> > > > enabled
> > > > > > when the log level is debug?
> > > > > > If so this might be a problem because finest can be way too much.
> > > > > >
> > > > > > I think geode's config and info both map to log4j info and I'm
> find
> > > > with
> > > > > > info logging both config and info.
> > > > > >
> > > > > >
> > > > > > On Wed, Mar 15, 2017 at 11:31 AM, Swapnil Bawaskar <
> > > > sbawas...@pivotal.io
> > > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > +1 to making the change and updating the docs to reflect only
> the
> > > new
> > > > > log
> > > > > > > levels.
> > > > > > >
> > > > > > > On Wed, Mar 15, 2017 at 10:45 AM Jinmei Liao <
> jil...@pivotal.io>
> > > > > wrote:
> > > > > > >
> > > > > > > > Hi, all,
> > > > > > > >
> > > > > > > > Geode, before using log4j for logging has implemented its own
> > > > > > LogWriters
> > > > > > > > and logLevels. Geode log levels has values like "finest,
> finer,
> > > > fine,
> > > > > > > > config, info, warning, error, severe".  We've moved away from
> > > using
> > > > > > these
> > > > > > > > log writers to favor using log4j logging. So, mostly, geode
> > logs
> > > > have
> > > > > > > log4j
> > > > > > > > log statements with levels like "fatal, error, warn, info,
> > > debug".
> > > > > > > >
> > > > > > > > But by examining our existing commands that has log-level
> > > options,
> > > > > > > > specifically "start server", "start locator", "alter
> runtime",
> > > > > "change
> > > > > > > > log-level", these commands are still accepting log-levels
> with
> > > > geode
> > > > > > log
> > > > > > > > levels, and under the cover, it has a mapping to the log4j
> > > levels.
> > > > > > Since
> > > > > > > we
> > > > > > > > are moving away from geode's own logging, I would like to
> > propose
> > > > > > > changing
> > > > > > > > these commands to use log4j log levels explicitly.
> > > > > > > >
> > > > > > > > To avoid breaking existing commands, we can provide a mapping
> > to
> > > > the
> > > > > > > log4j
> > > > > > > > levels after user provides an "old" log level, but at least I
> > > would
> > > > > > like
> > > > > > > to
> > > > > > > > have the auto complete start showing the log4j levels instead
> > of
> > > > the
> > > > > > > geode
> > > > > > > > log levels and move towards getting rid of these old levels
> > > > > completely.
> > > > > > > >
> > > > > > > > --
> > > > > > > > Cheers
> > > > > > > >
> > > > > > > > Jinmei
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > 

[jira] [Commented] (GEODE-2649) ExportLogsDUnitTest.testExportWithStartAndEndDateTimeFiltering fails with AssertionError

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2649:


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

GEODE-2649: Export logs does not use file creation time


> ExportLogsDUnitTest.testExportWithStartAndEndDateTimeFiltering fails with 
> AssertionError
> 
>
> Key: GEODE-2649
> URL: https://issues.apache.org/jira/browse/GEODE-2649
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh, tests
>Reporter: Kirk Lund
>Assignee: Jared Stewart
>  Labels: CI
>
> {noformat}
> org.apache.geode.management.internal.cli.commands.ExportLogsDUnitTest > 
> testExportWithStartAndEndDateTimeFiltering FAILED
> java.lang.AssertionError:
> Expected size:<3> but was:<2> in:
> <[/tmp/junit8723178147444223944/unzippedLogs/server-1,
> /tmp/junit8723178147444223944/unzippedLogs/server-2]>
> at 
> org.apache.geode.management.internal.cli.commands.ExportLogsDUnitTest.verifyZipFileContents(ExportLogsDUnitTest.java:225)
> at 
> org.apache.geode.management.internal.cli.commands.ExportLogsDUnitTest.testExportWithStartAndEndDateTimeFiltering(ExportLogsDUnitTest.java:155)
> 303 tests completed, 1 failed, 8 skipped
> {noformat}



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

[jira] [Resolved] (GEODE-2649) ExportLogsDUnitTest.testExportWithStartAndEndDateTimeFiltering fails with AssertionError

[Jared Stewart (JIRA)]

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

Jared Stewart resolved GEODE-2649.
--
Resolution: Fixed

> ExportLogsDUnitTest.testExportWithStartAndEndDateTimeFiltering fails with 
> AssertionError
> 
>
> Key: GEODE-2649
> URL: https://issues.apache.org/jira/browse/GEODE-2649
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh, tests
>Reporter: Kirk Lund
>Assignee: Jared Stewart
>  Labels: CI
> Fix For: 1.2.0
>
>
> {noformat}
> org.apache.geode.management.internal.cli.commands.ExportLogsDUnitTest > 
> testExportWithStartAndEndDateTimeFiltering FAILED
> java.lang.AssertionError:
> Expected size:<3> but was:<2> in:
> <[/tmp/junit8723178147444223944/unzippedLogs/server-1,
> /tmp/junit8723178147444223944/unzippedLogs/server-2]>
> at 
> org.apache.geode.management.internal.cli.commands.ExportLogsDUnitTest.verifyZipFileContents(ExportLogsDUnitTest.java:225)
> at 
> org.apache.geode.management.internal.cli.commands.ExportLogsDUnitTest.testExportWithStartAndEndDateTimeFiltering(ExportLogsDUnitTest.java:155)
> 303 tests completed, 1 failed, 8 skipped
> {noformat}



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

[jira] [Updated] (GEODE-2649) ExportLogsDUnitTest.testExportWithStartAndEndDateTimeFiltering fails with AssertionError

[Jared Stewart (JIRA)]

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

Jared Stewart updated GEODE-2649:
-
Fix Version/s: 1.2.0

> ExportLogsDUnitTest.testExportWithStartAndEndDateTimeFiltering fails with 
> AssertionError
> 
>
> Key: GEODE-2649
> URL: https://issues.apache.org/jira/browse/GEODE-2649
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh, tests
>Reporter: Kirk Lund
>Assignee: Jared Stewart
>  Labels: CI
> Fix For: 1.2.0
>
>
> {noformat}
> org.apache.geode.management.internal.cli.commands.ExportLogsDUnitTest > 
> testExportWithStartAndEndDateTimeFiltering FAILED
> java.lang.AssertionError:
> Expected size:<3> but was:<2> in:
> <[/tmp/junit8723178147444223944/unzippedLogs/server-1,
> /tmp/junit8723178147444223944/unzippedLogs/server-2]>
> at 
> org.apache.geode.management.internal.cli.commands.ExportLogsDUnitTest.verifyZipFileContents(ExportLogsDUnitTest.java:225)
> at 
> org.apache.geode.management.internal.cli.commands.ExportLogsDUnitTest.testExportWithStartAndEndDateTimeFiltering(ExportLogsDUnitTest.java:155)
> 303 tests completed, 1 failed, 8 skipped
> {noformat}



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

[jira] [Created] (GEODE-2685) request that ParitionedRegion getStatistics be a supported operation

[Darrel Schneider (JIRA)]

Darrel Schneider created GEODE-2685:
---

 Summary: request that ParitionedRegion getStatistics be a 
supported operation
 Key: GEODE-2685
 URL: https://issues.apache.org/jira/browse/GEODE-2685
 Project: Geode
  Issue Type: Improvement
  Components: regions
Reporter: Darrel Schneider


The current implementation of PartitionedRegion getStatistics always throws 
UnsupportedOperationException.
It would be nice for this operation to be supported.

I think the statistics it returns could be a snapshot of the state of the local 
buckets in the PR at the time getStatistics is called. This could be 
implemented by iterating over the local internal BucketRegions and asking them 
for their statistics. For a PR accessor (no local buckets) the only stat that 
is needed is misses since you have no local buckets and every operation is a 
miss.




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

[jira] [Updated] (GEODE-2676) RegionMBean statistics wrong on partitioned regions

[Darrel Schneider (JIRA)]

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

Darrel Schneider updated GEODE-2676:

Description: 
RegionMBean attributes hitCount, hitRatio, missCount, lastAccessedTime, and 
lastModifiedTime will always be 0 for an mbean that represents an partitioned 
region.

The gettors for these methods may call getStatistics() which on a PR always 
throws UnsupportedOperationException. So this exception might even get exposed 
to customers.

The initialization of RegionMBeanBridge calls getStatisticsEnabled() which 
returns true on a PartitionedRegion. This does have meaning on a PR but it does 
not mean that getStatistics() is a supported operation. On a PR setting 
statistics-enabled causes each region-entry to also keep track of its last 
access time.
It is true that if getStatisticsEnabled() is false then you should not call 
getStatistics. But the opposite is not true. Since we currently have regions 
that do not support getStatistics(), the code in RegionMBeanBridge should catch 
UnsupportedOperationException and handle it. I would suggest that the 
constructor be changed that initializes the "isStatisticsEnabled" field. 
Instead of only calling getStatisticsEnabled() it should also call 
getStatistics(). Something like this:
{noformat}
{
  boolean useGetStatistics = regAttrs.getStatisticsEnabled();
  if (useGetStatistics) {
try {
  region.getStatistics();
} catch (UnsupportedOperationException ex) {
  useGetStatistics = false;
}
  }
  this.isStatisticsEnabled = useGetStatistics;
}
{noformat}
That way in a future release if PRs are changed to support getStatistics this 
code will start calling it without having a direct dependency on the 
implementation of PartitionedRegion.

https://issues.apache.org/jira/browse/GEODE-2685 is a request to support 
getStatistics on PRs.


  was:
RegionMBean attributes hitCount, hitRatio, missCount, lastAccessedTime, and 
lastModifiedTime will always be 0 for an mbean that represents an partitioned 
region.

The gettors for these methods may call getStatistics() which on a PR always 
throws UnsupportedOperationException. So this exception might even get exposed 
to customers.

The initialization of RegionMBeanBridge calls getStatisticsEnabled() which 
returns true on a PartitionedRegion. This does have meaning on a PR but it does 
not mean that getStatistics() is a supported operation. On a PR setting 
statistics-enabled causes each region-entry to also keep track of its last 
access time.
It is true that if getStatisticsEnabled() is false then you should not call 
getStatistics. But the opposite is not true. Since we currently have regions 
that do not support getStatistics(), the code in RegionMBeanBridge should catch 
UnsupportedOperationException and handle it. I would suggest that the 
constructor be changed that initializes the "isStatisticsEnabled" field. 
Instead of only calling getStatisticsEnabled() it should also call 
getStatistics(). Something like this:
{noformat}
{
  boolean useGetStatistics = regAttrs.getStatisticsEnabled();
  if (useGetStatistics) {
try {
  region.getStatistics();
} catch (UnsupportedOperationException ex) {
  useGetStatistics = false;
}
  }
  this.isStatisticsEnabled = useGetStatistics;
}
{noformat}
That way in a future release if PRs are changed to support getStatistics this 
code will start calling it without having a direct dependency on the 
implementation of PartitionedRegion.

Another ticket will be filed requesting that getStatistics to become a 
supported operation on PRs. 


> RegionMBean statistics wrong on partitioned regions
> ---
>
> Key: GEODE-2676
> URL: https://issues.apache.org/jira/browse/GEODE-2676
> Project: Geode
>  Issue Type: Bug
>Reporter: Fred Krone
>Priority: Minor
>  Labels: jmx
>
> RegionMBean attributes hitCount, hitRatio, missCount, lastAccessedTime, and 
> lastModifiedTime will always be 0 for an mbean that represents an partitioned 
> region.
> The gettors for these methods may call getStatistics() which on a PR always 
> throws UnsupportedOperationException. So this exception might even get 
> exposed to customers.
> The initialization of RegionMBeanBridge calls getStatisticsEnabled() which 
> returns true on a PartitionedRegion. This does have meaning on a PR but it 
> does not mean that getStatistics() is a supported operation. On a PR setting 
> statistics-enabled causes each region-entry to also keep track of its last 
> access time.
> It is true that if getStatisticsEnabled() is false then you should not call 
> getStatistics. But the opposite is not true. Since we currently have regions 
> that do not support getStatistics(), t

[GitHub] geode pull request #428: GEODE-2649: Export logs does not use file creation ...

[jaredjstewart]

Github user jaredjstewart closed the pull request at:

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


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

[GitHub] geode issue #428: GEODE-2649: Export logs does not use file creation time

[jaredjstewart]

Github user jaredjstewart commented on the issue:

https://github.com/apache/geode/pull/428
  
Merged as 400552a


---
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-2649) ExportLogsDUnitTest.testExportWithStartAndEndDateTimeFiltering fails with AssertionError

[ASF GitHub Bot (JIRA)]

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

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

Github user jaredjstewart closed the pull request at:

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


> ExportLogsDUnitTest.testExportWithStartAndEndDateTimeFiltering fails with 
> AssertionError
> 
>
> Key: GEODE-2649
> URL: https://issues.apache.org/jira/browse/GEODE-2649
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh, tests
>Reporter: Kirk Lund
>Assignee: Jared Stewart
>  Labels: CI
> Fix For: 1.2.0
>
>
> {noformat}
> org.apache.geode.management.internal.cli.commands.ExportLogsDUnitTest > 
> testExportWithStartAndEndDateTimeFiltering FAILED
> java.lang.AssertionError:
> Expected size:<3> but was:<2> in:
> <[/tmp/junit8723178147444223944/unzippedLogs/server-1,
> /tmp/junit8723178147444223944/unzippedLogs/server-2]>
> at 
> org.apache.geode.management.internal.cli.commands.ExportLogsDUnitTest.verifyZipFileContents(ExportLogsDUnitTest.java:225)
> at 
> org.apache.geode.management.internal.cli.commands.ExportLogsDUnitTest.testExportWithStartAndEndDateTimeFiltering(ExportLogsDUnitTest.java:155)
> 303 tests completed, 1 failed, 8 skipped
> {noformat}



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

[jira] [Commented] (GEODE-2649) ExportLogsDUnitTest.testExportWithStartAndEndDateTimeFiltering fails with AssertionError

[ASF GitHub Bot (JIRA)]

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

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

Github user jaredjstewart commented on the issue:

https://github.com/apache/geode/pull/428
  
Merged as 400552a


> ExportLogsDUnitTest.testExportWithStartAndEndDateTimeFiltering fails with 
> AssertionError
> 
>
> Key: GEODE-2649
> URL: https://issues.apache.org/jira/browse/GEODE-2649
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh, tests
>Reporter: Kirk Lund
>Assignee: Jared Stewart
>  Labels: CI
> Fix For: 1.2.0
>
>
> {noformat}
> org.apache.geode.management.internal.cli.commands.ExportLogsDUnitTest > 
> testExportWithStartAndEndDateTimeFiltering FAILED
> java.lang.AssertionError:
> Expected size:<3> but was:<2> in:
> <[/tmp/junit8723178147444223944/unzippedLogs/server-1,
> /tmp/junit8723178147444223944/unzippedLogs/server-2]>
> at 
> org.apache.geode.management.internal.cli.commands.ExportLogsDUnitTest.verifyZipFileContents(ExportLogsDUnitTest.java:225)
> at 
> org.apache.geode.management.internal.cli.commands.ExportLogsDUnitTest.testExportWithStartAndEndDateTimeFiltering(ExportLogsDUnitTest.java:155)
> 303 tests completed, 1 failed, 8 skipped
> {noformat}



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

[jira] [Assigned] (GEODE-2671) when a locator is started with a jmx-manager-port that is not 1099, the embedded pulse server still tries to connect to jmx using 1099

[Kevin Duling (JIRA)]

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

Kevin Duling reassigned GEODE-2671:
---

Assignee: Kevin Duling

> when a locator is started with a jmx-manager-port that is not 1099, the 
> embedded pulse server still tries to connect to jmx using 1099
> --
>
> Key: GEODE-2671
> URL: https://issues.apache.org/jira/browse/GEODE-2671
> Project: Geode
>  Issue Type: Bug
>  Components: pulse
>Reporter: Jinmei Liao
>Assignee: Kevin Duling
>
> embedded pulse does not use the jmx-manager-port used by the locator to 
> connect.



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

[jira] [Created] (GEODE-2686) Remove JarClassLoader

[Jared Stewart (JIRA)]

Jared Stewart created GEODE-2686:


 Summary: Remove JarClassLoader
 Key: GEODE-2686
 URL: https://issues.apache.org/jira/browse/GEODE-2686
 Project: Geode
  Issue Type: Sub-task
  Components: management
Reporter: Jared Stewart


Before we can limit the scanning of deployed jars, we need to extricate 
JarClassLoader, as its implementation eagerly loads all classes into memory.



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

[jira] [Assigned] (GEODE-2290) Provide way to limit scanning of deployed jars

[Jared Stewart (JIRA)]

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

Jared Stewart reassigned GEODE-2290:


Assignee: Jared Stewart

> Provide way to limit scanning of deployed jars
> --
>
> Key: GEODE-2290
> URL: https://issues.apache.org/jira/browse/GEODE-2290
> Project: Geode
>  Issue Type: Improvement
>  Components: gfsh, management
>Reporter: Kirk Lund
>Assignee: Jared Stewart
>  Labels: ClassLoader, DeployCommand, deploy, gfsh
>
> Currently if you use the GFSH command "deploy jar" the deployed jar will be 
> scanned in such a way that the deployer will load and resolve every .class 
> file in the jar file. The original intention of "deploy jar" was that only 
> Functions would be deployed. Any .class that is found to be a Function is 
> automatically registered with the FunctionService. 
> You can also include implementations of other Apache Geode callbacks such as 
> CacheListener. If you then follow up the deploy with "alter region" you can 
> alter the region to add the CacheListener or other callback.
> Some users have reported trying to deploy a jar with much more than just 
> Functions or CacheListeners or domain classes used for Region Entries. If the 
> jar includes a class that the callbacks or domain classes don't directly use 
> but that class requires a missing transitive dependency, then the deployer 
> will generate a NoClassDefFoundError when it tries to load and resolve that 
> class.
> Along with the potential NoClassDefFoundError, forcing every .class to be 
> loaded and resolved can consume a lot of PermGen memory.
> Various ideas have been tossed around to allow someone to deploy such a jar 
> without having the deployer generate NoClassDefFoundError. This requires 
> something like one of the following approaches:
> 1) add a new --do-not-deploy option flag
> 2) comma-delimited list of classes to load and deploy
> 3) regex list of classes to load and deploy
> 4) have I missed something?
> This would give the User better control over which classes to actually load 
> and resolve.
> [NOTE: I'll update this ticket based on feedback and discussion on 
> dev@geode.apache.org]



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

[jira] [Commented] (GEODE-2517) Data transfer of size > 2GB from server to client results in a hang and eventual timeout exception

[nabarun (JIRA)]

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

nabarun commented on GEODE-2517:


[~bschuchardt] I simply created a dummy class with a string city and also 
filled it with arrays of integers, etc. lot of garbage data to increase the 
size. it was a trial an error situation where I kept incrementing the garbage 
data until i hit the error.
[~hitesh.khamesra] No , i did not set any system properties. 

> Data transfer of size > 2GB from server to client results in a hang and 
> eventual timeout exception
> --
>
> Key: GEODE-2517
> URL: https://issues.apache.org/jira/browse/GEODE-2517
> Project: Geode
>  Issue Type: Bug
>  Components: client/server
>Affects Versions: 1.1.0
>Reporter: nabarun
>
> *Situation*:
> 1. Create a server and client.
> 2. Fill the server with a large amount of data. 
> 3. Create a query that will result in over 600,000 entries as result.
> 4. Chunk the result set in such a way that one chunk will result in a size 
> greater than 2GB
> 5. Execute the query from the client.
> *Expected*:
> Message too large exception.
> *Cause / Fix for the issue*:
> If the number of parts to be transmitted is one then in sendBytes()
> {code:title=Message.java}
> for (int i = 0; i < this.numberOfParts; i++) {
>   Part part = this.partsList[i];
>   headerLen += PART_HEADER_SIZE;
>   totalPartLen += part.getLength();
> }
> {code}
> * Here the part.getLength() is an int, so if the size is greater than 2GB we 
> have already overflowed the int barrier and we are putting a negative value 
> in totalPartLen
> so when we do the below check :
> {code:title=Message.java}
> if ((headerLen + totalPartLen) > Integer.MAX_VALUE) {
>   throw new MessageTooLargeException(
>   "Message size (" + (headerLen + totalPartLen) + ") exceeds 
> maximum integer value");
> }
> {code}
> The comparison is between a negative number and positive number 
> [Integer.MAX_VALUE] hence it will always skip this loop.
> and ultimately result in this exception.
> {noformat}
> java.io.IOException: Part length ( -508,098,123 ) and number of parts ( 1 ) 
> inconsistent
>   at 
> com.gemstone.gemfire.internal.cache.tier.sockets.Message.readPayloadFields(Message.java:836)
>   at 
> com.gemstone.gemfire.internal.cache.tier.sockets.ChunkedMessage.readChunk(ChunkedMessage.java:276)
>   at 
> com.gemstone.gemfire.internal.cache.tier.sockets.ChunkedMessage.receiveChunk(ChunkedMessage.java:220)
>   at 
> com.gemstone.gemfire.cache.client.internal.ExecuteRegionFunctionOp$ExecuteRegionFunctionOpImpl.processResponse(ExecuteRegionFunctionOp.java:482)
>   at 
> com.gemstone.gemfire.cache.client.internal.AbstractOp.processResponse(AbstractOp.java:215)
>   at 
> com.gemstone.gemfire.cache.client.internal.AbstractOp.attemptReadResponse(AbstractOp.java:153)
>   at 
> com.gemstone.gemfire.cache.client.internal.AbstractOp.attempt(AbstractOp.java:369)
>   at 
> com.gemstone.gemfire.cache.client.internal.ConnectionImpl.execute(ConnectionImpl.java:252)
>   at 
> com.gemstone.gemfire.cache.client.internal.pooling.PooledConnection.execute(PooledConnection.java:319)
>   at 
> com.gemstone.gemfire.cache.client.internal.OpExecutorImpl.executeWithPossibleReAuthentication(OpExecutorImpl.java:933)
>   at 
> com.gemstone.gemfire.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:158)
>   at 
> com.gemstone.gemfire.cache.client.internal.PoolImpl.execute(PoolImpl.java:716)
>   at 
> com.gemstone.gemfire.cache.client.internal.ExecuteRegionFunctionOp.execute(ExecuteRegionFunctionOp.java:159)
>   at 
> com.gemstone.gemfire.cache.client.internal.ServerRegionProxy.executeFunction(ServerRegionProxy.java:801)
>   at 
> com.gemstone.gemfire.internal.cache.execute.ServerRegionFunctionExecutor.executeOnServer(ServerRegionFunctionExecutor.java:212)
>   at 
> com.gemstone.gemfire.internal.cache.execute.ServerRegionFunctionExecutor.executeFunction(ServerRegionFunctionExecutor.java:165)
>   at 
> com.gemstone.gemfire.internal.cache.execute.ServerRegionFunctionExecutor.execute(ServerRegionFunctionExecutor.java:363)
>   at com.bookshop.buslogic.TestClient.run(TestClient.java:40)
>   at com.bookshop.buslogic.TestClient.main(TestClient.java:21)
> {noformat}



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

[GitHub] geode-native pull request #60: GEODE-2521 geode native docs: Document instal...

[davebarnes97]

GitHub user davebarnes97 opened a pull request:

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

GEODE-2521 geode native docs: Document installation from source

Adds instructions for building from source.
Removes binary installation & uninstallation, which were artifacts from the 
proprietary code.

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

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

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

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


commit 5e194a7dcab8ab059fcca856d3765e40a97e4c3b
Author: Dave Barnes 
Date:   2017-03-16T22:52:12Z

GEODE-2521 geode native docs: Document installation from source




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

[jira] [Commented] (GEODE-2521) geode native docs: Document installation from source

[ASF GitHub Bot (JIRA)]

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

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

GitHub user davebarnes97 opened a pull request:

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

GEODE-2521 geode native docs: Document installation from source

Adds instructions for building from source.
Removes binary installation & uninstallation, which were artifacts from the 
proprietary code.

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

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

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

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


commit 5e194a7dcab8ab059fcca856d3765e40a97e4c3b
Author: Dave Barnes 
Date:   2017-03-16T22:52:12Z

GEODE-2521 geode native docs: Document installation from source




> geode native docs: Document installation from source
> 
>
> Key: GEODE-2521
> URL: https://issues.apache.org/jira/browse/GEODE-2521
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Dave Barnes
>Assignee: Dave Barnes
>
> Update installation instructions to include building from source. Binary 
> distributions will also (presumably) be available on the website's Releases 
> page. (See the installation section of the Geode user manual for a model to 
> follow.)



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

Re: Review Request 57729: GEODE-2634: use log4j levels for auto-completion

[Jinmei Liao]

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

(Updated March 17, 2017, 6:48 p.m.)


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


Repository: geode


Description
---

* change the auto complete to use log4j levels.
* be able to handle both log4j levels and logwriter levels in the commands
* add validation of log level whenever possible for these commands
* Move the conversion between the two to a LogLevel class and add unit tests


Diffs
-

  geode-core/src/main/java/org/apache/geode/LogWriter.java 
242433fb0bd093df1ebbccce388d4b10a510f391 
  
geode-core/src/main/java/org/apache/geode/admin/internal/DistributedSystemConfigImpl.java
 a89d3904fc999e8a956a06de02b73411987540ee 
  
geode-core/src/main/java/org/apache/geode/distributed/internal/AbstractDistributionConfig.java
 decb61d45b7854005b9c5ab554c4e8ead82dcfd9 
  geode-core/src/main/java/org/apache/geode/i18n/LogWriterI18n.java 
b9a4df3068f0a3474d9125743e9da0b44e981a5f 
  
geode-core/src/main/java/org/apache/geode/internal/admin/remote/RemoteAlert.java
 1783e90ecbe2315b8aa496c44cd9fd59e9eb71ba 
  geode-core/src/main/java/org/apache/geode/internal/logging/GemFireLevel.java 
0e1dc6ecd97e6132a29044ce29d68769de527336 
  geode-core/src/main/java/org/apache/geode/internal/logging/LogWriterImpl.java 
57f0a5cfaf4f975c68be2cc6a1850d5da843259b 
  
geode-core/src/main/java/org/apache/geode/internal/logging/log4j/LogLevel.java 
PRE-CREATION 
  
geode-core/src/main/java/org/apache/geode/internal/logging/log4j/LogWriterAppender.java
 031a3068d4e188be9f9b7a802f26927f3cacd3f7 
  
geode-core/src/main/java/org/apache/geode/internal/logging/log4j/LogWriterLogger.java
 f56599b5490d2dbbacd30a121d135891c67460a4 
  
geode-core/src/main/java/org/apache/geode/management/internal/MemberMessenger.java
 25366f9733305e15a65c24c2f24843b54e32c1dd 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ConfigCommands.java
 8c633828f2bb1e110cad98d016e6bf68f866f5e2 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ExportLogCommand.java
 678fdaf89547326c3743093edea35a264809e64d 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/LauncherLifecycleCommands.java
 3ad93ce3b63730f699ae8b7820f277221342adab 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/MiscellaneousCommands.java
 1fc60271d70982f83fd078ea36a61bfcedb0c5cc 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/converters/LogLevelConverter.java
 39a110c679c43ff192aedcd73a6c68951efffaed 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/ChangeLogLevelFunction.java
 99f37cc8d2d3941e818eaf1a10b9d888f0e3b342 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/ExportLogsFunction.java
 62026fb749fe220c1dfe16ea2255f8ebfe5958d1 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/util/LogLevelExtractor.java
 bbeb5c75a73f3749e7a4f62d76533b847f9ce317 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/util/ReadWriteFile.java
 958ed0ec98bb0e3cd3656f914ffe03b16b38e582 
  
geode-core/src/test/java/org/apache/geode/distributed/internal/DistributionConfigJUnitTest.java
 080136055feb304ebe6bfe28a0da72e67dfde21f 
  
geode-core/src/test/java/org/apache/geode/internal/logging/log4j/LogLevelTest.java
 PRE-CREATION 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsInterceptorJUnitTest.java
 97ed686dcd5a159613f978a4311a44b72b30fefd 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/LogLevelInterceptorTest.java
 PRE-CREATION 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/converters/LogLevelConverterTest.java
 PRE-CREATION 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/functions/ExportLogsFunctionIntegrationTest.java
 cdc57667d5bb06ae904fb04b6b3919a7e879bc7e 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/util/LogLevelExtractorTest.java
 fd7d68bfd2a26d11f3f971bb089476105e46 
  
geode-web/src/test/java/org/apache/geode/management/internal/cli/commands/CommandOverHttpDUnitTest.java
 5f4cd74b8af81ae3bbeff04d6ce44a5c4ac9ec59 


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


Testing (updated)
---

precheckin successful


Thanks,

Jinmei Liao

[jira] [Commented] (GEODE-2521) geode native docs: Document installation from source

[Dave Barnes (JIRA)]

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

Dave Barnes commented on GEODE-2521:


No binary releases are planned. Scope of this ticket reduced to describing 
build from source, only.

> geode native docs: Document installation from source
> 
>
> Key: GEODE-2521
> URL: https://issues.apache.org/jira/browse/GEODE-2521
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Dave Barnes
>Assignee: Dave Barnes
>
> Update installation instructions to include building from source. Binary 
> distributions will also (presumably) be available on the website's Releases 
> page. (See the installation section of the Geode user manual for a model to 
> follow.)



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

[GitHub] geode-native pull request #60: GEODE-2521 geode native docs: Document instal...

[echobravopapa]

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

https://github.com/apache/geode-native/pull/60#discussion_r106726114
  
--- Diff: BUILDING.md ---
@@ -77,7 +77,7 @@ Due to limitations in CMake, the documentation must be 
built as a separate step
 
 ### Required Tools
 * [Visual Studio 2013](https://www.visualstudio.com) or newer
-* [Cygwin](https://www.cygwin.com/)
+* [Cygwin](https://www.cygwin.com/) (for the patch tool)
--- End diff --

@davebarnes97 I think we can remove reference to Cygwin, we get the patch 
tool from GNUWin now... if I am mistaken @dgkimura will set me straight


---
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-2521) geode native docs: Document installation from source

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/geode-native/pull/60#discussion_r106726114
  
--- Diff: BUILDING.md ---
@@ -77,7 +77,7 @@ Due to limitations in CMake, the documentation must be 
built as a separate step
 
 ### Required Tools
 * [Visual Studio 2013](https://www.visualstudio.com) or newer
-* [Cygwin](https://www.cygwin.com/)
+* [Cygwin](https://www.cygwin.com/) (for the patch tool)
--- End diff --

@davebarnes97 I think we can remove reference to Cygwin, we get the patch 
tool from GNUWin now... if I am mistaken @dgkimura will set me straight


> geode native docs: Document installation from source
> 
>
> Key: GEODE-2521
> URL: https://issues.apache.org/jira/browse/GEODE-2521
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Dave Barnes
>Assignee: Dave Barnes
>
> Update installation instructions to include building from source. Binary 
> distributions will also (presumably) be available on the website's Releases 
> page. (See the installation section of the Geode user manual for a model to 
> follow.)



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

[jira] [Updated] (GEODE-2517) Data transfer of size > 2GB from server to client results in a hang and eventual timeout exception

[Hitesh Khamesra (JIRA)]

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

Hitesh Khamesra updated GEODE-2517:
---
Component/s: docs

> Data transfer of size > 2GB from server to client results in a hang and 
> eventual timeout exception
> --
>
> Key: GEODE-2517
> URL: https://issues.apache.org/jira/browse/GEODE-2517
> Project: Geode
>  Issue Type: Bug
>  Components: client/server, docs
>Affects Versions: 1.1.0
>Reporter: nabarun
>
> *Situation*:
> 1. Create a server and client.
> 2. Fill the server with a large amount of data. 
> 3. Create a query that will result in over 600,000 entries as result.
> 4. Chunk the result set in such a way that one chunk will result in a size 
> greater than 2GB
> 5. Execute the query from the client.
> *Expected*:
> Message too large exception.
> *Cause / Fix for the issue*:
> If the number of parts to be transmitted is one then in sendBytes()
> {code:title=Message.java}
> for (int i = 0; i < this.numberOfParts; i++) {
>   Part part = this.partsList[i];
>   headerLen += PART_HEADER_SIZE;
>   totalPartLen += part.getLength();
> }
> {code}
> * Here the part.getLength() is an int, so if the size is greater than 2GB we 
> have already overflowed the int barrier and we are putting a negative value 
> in totalPartLen
> so when we do the below check :
> {code:title=Message.java}
> if ((headerLen + totalPartLen) > Integer.MAX_VALUE) {
>   throw new MessageTooLargeException(
>   "Message size (" + (headerLen + totalPartLen) + ") exceeds 
> maximum integer value");
> }
> {code}
> The comparison is between a negative number and positive number 
> [Integer.MAX_VALUE] hence it will always skip this loop.
> and ultimately result in this exception.
> {noformat}
> java.io.IOException: Part length ( -508,098,123 ) and number of parts ( 1 ) 
> inconsistent
>   at 
> com.gemstone.gemfire.internal.cache.tier.sockets.Message.readPayloadFields(Message.java:836)
>   at 
> com.gemstone.gemfire.internal.cache.tier.sockets.ChunkedMessage.readChunk(ChunkedMessage.java:276)
>   at 
> com.gemstone.gemfire.internal.cache.tier.sockets.ChunkedMessage.receiveChunk(ChunkedMessage.java:220)
>   at 
> com.gemstone.gemfire.cache.client.internal.ExecuteRegionFunctionOp$ExecuteRegionFunctionOpImpl.processResponse(ExecuteRegionFunctionOp.java:482)
>   at 
> com.gemstone.gemfire.cache.client.internal.AbstractOp.processResponse(AbstractOp.java:215)
>   at 
> com.gemstone.gemfire.cache.client.internal.AbstractOp.attemptReadResponse(AbstractOp.java:153)
>   at 
> com.gemstone.gemfire.cache.client.internal.AbstractOp.attempt(AbstractOp.java:369)
>   at 
> com.gemstone.gemfire.cache.client.internal.ConnectionImpl.execute(ConnectionImpl.java:252)
>   at 
> com.gemstone.gemfire.cache.client.internal.pooling.PooledConnection.execute(PooledConnection.java:319)
>   at 
> com.gemstone.gemfire.cache.client.internal.OpExecutorImpl.executeWithPossibleReAuthentication(OpExecutorImpl.java:933)
>   at 
> com.gemstone.gemfire.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:158)
>   at 
> com.gemstone.gemfire.cache.client.internal.PoolImpl.execute(PoolImpl.java:716)
>   at 
> com.gemstone.gemfire.cache.client.internal.ExecuteRegionFunctionOp.execute(ExecuteRegionFunctionOp.java:159)
>   at 
> com.gemstone.gemfire.cache.client.internal.ServerRegionProxy.executeFunction(ServerRegionProxy.java:801)
>   at 
> com.gemstone.gemfire.internal.cache.execute.ServerRegionFunctionExecutor.executeOnServer(ServerRegionFunctionExecutor.java:212)
>   at 
> com.gemstone.gemfire.internal.cache.execute.ServerRegionFunctionExecutor.executeFunction(ServerRegionFunctionExecutor.java:165)
>   at 
> com.gemstone.gemfire.internal.cache.execute.ServerRegionFunctionExecutor.execute(ServerRegionFunctionExecutor.java:363)
>   at com.bookshop.buslogic.TestClient.run(TestClient.java:40)
>   at com.bookshop.buslogic.TestClient.main(TestClient.java:21)
> {noformat}



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

[jira] [Commented] (GEODE-2517) Data transfer of size > 2GB from server to client results in a hang and eventual timeout exception

[Hitesh Khamesra (JIRA)]

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

Hitesh Khamesra commented on GEODE-2517:


[~nabarun] Thanks. I am sure there is something in QueryEngine, which take 
cares of chunking the results. But if someone is executing function then it 
needs to return results in a chunk or at the safer side just send one object at 
a time(assuming the object is not crossing this 2gb limit). We definitely need 
to fix that ugly code. 

I will check with docs team([~jmcallis...@pivotal.io]) to see if something is 
documented for this (best practices)

> Data transfer of size > 2GB from server to client results in a hang and 
> eventual timeout exception
> --
>
> Key: GEODE-2517
> URL: https://issues.apache.org/jira/browse/GEODE-2517
> Project: Geode
>  Issue Type: Bug
>  Components: client/server, docs
>Affects Versions: 1.1.0
>Reporter: nabarun
>
> *Situation*:
> 1. Create a server and client.
> 2. Fill the server with a large amount of data. 
> 3. Create a query that will result in over 600,000 entries as result.
> 4. Chunk the result set in such a way that one chunk will result in a size 
> greater than 2GB
> 5. Execute the query from the client.
> *Expected*:
> Message too large exception.
> *Cause / Fix for the issue*:
> If the number of parts to be transmitted is one then in sendBytes()
> {code:title=Message.java}
> for (int i = 0; i < this.numberOfParts; i++) {
>   Part part = this.partsList[i];
>   headerLen += PART_HEADER_SIZE;
>   totalPartLen += part.getLength();
> }
> {code}
> * Here the part.getLength() is an int, so if the size is greater than 2GB we 
> have already overflowed the int barrier and we are putting a negative value 
> in totalPartLen
> so when we do the below check :
> {code:title=Message.java}
> if ((headerLen + totalPartLen) > Integer.MAX_VALUE) {
>   throw new MessageTooLargeException(
>   "Message size (" + (headerLen + totalPartLen) + ") exceeds 
> maximum integer value");
> }
> {code}
> The comparison is between a negative number and positive number 
> [Integer.MAX_VALUE] hence it will always skip this loop.
> and ultimately result in this exception.
> {noformat}
> java.io.IOException: Part length ( -508,098,123 ) and number of parts ( 1 ) 
> inconsistent
>   at 
> com.gemstone.gemfire.internal.cache.tier.sockets.Message.readPayloadFields(Message.java:836)
>   at 
> com.gemstone.gemfire.internal.cache.tier.sockets.ChunkedMessage.readChunk(ChunkedMessage.java:276)
>   at 
> com.gemstone.gemfire.internal.cache.tier.sockets.ChunkedMessage.receiveChunk(ChunkedMessage.java:220)
>   at 
> com.gemstone.gemfire.cache.client.internal.ExecuteRegionFunctionOp$ExecuteRegionFunctionOpImpl.processResponse(ExecuteRegionFunctionOp.java:482)
>   at 
> com.gemstone.gemfire.cache.client.internal.AbstractOp.processResponse(AbstractOp.java:215)
>   at 
> com.gemstone.gemfire.cache.client.internal.AbstractOp.attemptReadResponse(AbstractOp.java:153)
>   at 
> com.gemstone.gemfire.cache.client.internal.AbstractOp.attempt(AbstractOp.java:369)
>   at 
> com.gemstone.gemfire.cache.client.internal.ConnectionImpl.execute(ConnectionImpl.java:252)
>   at 
> com.gemstone.gemfire.cache.client.internal.pooling.PooledConnection.execute(PooledConnection.java:319)
>   at 
> com.gemstone.gemfire.cache.client.internal.OpExecutorImpl.executeWithPossibleReAuthentication(OpExecutorImpl.java:933)
>   at 
> com.gemstone.gemfire.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:158)
>   at 
> com.gemstone.gemfire.cache.client.internal.PoolImpl.execute(PoolImpl.java:716)
>   at 
> com.gemstone.gemfire.cache.client.internal.ExecuteRegionFunctionOp.execute(ExecuteRegionFunctionOp.java:159)
>   at 
> com.gemstone.gemfire.cache.client.internal.ServerRegionProxy.executeFunction(ServerRegionProxy.java:801)
>   at 
> com.gemstone.gemfire.internal.cache.execute.ServerRegionFunctionExecutor.executeOnServer(ServerRegionFunctionExecutor.java:212)
>   at 
> com.gemstone.gemfire.internal.cache.execute.ServerRegionFunctionExecutor.executeFunction(ServerRegionFunctionExecutor.java:165)
>   at 
> com.gemstone.gemfire.internal.cache.execute.ServerRegionFunctionExecutor.execute(ServerRegionFunctionExecutor.java:363)
>   at com.bookshop.buslogic.TestClient.run(TestClient.java:40)
>   at com.bookshop.buslogic.TestClient.main(TestClient.java:21)
> {noformat}



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

[jira] [Commented] (GEODE-2639) Create Dunit tests to validate region expiration behavior with Lucene indexes

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2639:


Commit eeb01bbc97ca6f3f4f07115d21aba43400191e41 in geode's branch 
refs/heads/feature/GEODE-2420 from [~huynhja]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=eeb01bb ]

GEODE-2639: Added a wait for flush to avoid flakiness in test


> Create Dunit tests to validate region expiration behavior with Lucene indexes
> -
>
> Key: GEODE-2639
> URL: https://issues.apache.org/jira/browse/GEODE-2639
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: nabarun
>Assignee: nabarun
> Fix For: 1.2.0
>
>
> If region is configured for expiration with a destroy action,  the destroy 
> operation must remove entries from the Lucene index as well.



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

[jira] [Commented] (GEODE-2379) Document new behavior of export logs

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2379:


Commit e39aff223d662c018464a40a2deb357e00e16e9f in geode's branch 
refs/heads/feature/GEODE-2420 from [~dbarnes97]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=e39aff2 ]

GEODE-2379 Document new behavior of export logs
This closes #425


> Document new behavior of export logs
> 
>
> Key: GEODE-2379
> URL: https://issues.apache.org/jira/browse/GEODE-2379
> Project: Geode
>  Issue Type: Sub-task
>  Components: docs
>Reporter: Joey McAllister
>Assignee: Dave Barnes
>
> the new command help: 
> NAME
> export logs
> IS AVAILABLE
> false
> SYNOPSIS
> Export the log files for a member or members.
> SYNTAX
> export logs [--dir=value] [--group=value(,value)*] 
> [--member=value(,value)*] [--log-level=value] [--only-log-level=value] 
> [--merge-log=value] [--start-time=value] [--end-time=value] 
> [--logs-only(=value)?] [--stats-only(=value)?]
> PARAMETERS
> dir
> Local directory to which log files will be written. This is only used 
> when you are exporting logs using http connection. If not specified, user.dir 
> will be used.
> Required: false
> group
> Group of members whose log files will be exported.
> Required: false
> member
> Name/Id of the member whose log files will be exported.
> Required: false
> log-level
> Minimum level of log entries to export. Valid values are: fatal, 
> error, warn, info, debug, trace and all.  The default is "INFO".
> Required: false
> Default (if the parameter is not specified): INFO
> only-log-level
> Whether to only include those entries that exactly match the 
> --log-level specified.
> Required: false
> Default (if the parameter is not specified): false
> merge-log
> Whether to merge logs after exporting to the target directory.  -- 
> deprecated
> Required: false
> Default (if the parameter is not specified): false
> start-time
> Log entries that occurred after this time will be exported. The 
> default is no limit. Format: /MM/dd/HH/mm/ss/SSS/z OR /MM/dd
> Required: false
> end-time
> Log entries that occurred before this time will be exported. The 
> default is no limit. Format: /MM/dd/HH/mm/ss/SSS/z OR /MM/dd
> Required: false
> logs-only
> Whether to only export logs
> Required: false
> Default (if the parameter is specified without value): true
> Default (if the parameter is not specified): false
> stats-only
> Whether to only export statistics
> Required: false
> Default (if the parameter is specified without value): true
> Default (if the parameter is not specified): false
> changes are:  --dir is not required anymore. added logs-only and stats-only 
> options. --merge-log is deprecated, group and member can be comma separated 
> strings.
> Also note down in the docs: when this command is executed over jmx, the 
> exported logs will be saved as exportedlogs_xxx.zip in the connected 
> locator's working directory. If executed over http, the zip will be saved in 
> specified dir in the user's client machine.



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

[jira] [Commented] (GEODE-2645) Refactor CacheLogRollDUnitTest to be an IntegrationTest

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2645:


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

GEODE-2645: rewrite test to fix flakiness and improve readability


> Refactor CacheLogRollDUnitTest to be an IntegrationTest
> ---
>
> Key: GEODE-2645
> URL: https://issues.apache.org/jira/browse/GEODE-2645
> Project: Geode
>  Issue Type: Wish
>  Components: logging, tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
> Fix For: 1.2.0
>
>
> CacheLogRollDUnitTest appears to only use one JVM so it should be ported from 
> using DUnit to being a more simple IntegrationTest.
> It also has 4 flaky test bugs:
> * GEODE-674
> * GEODE-675
> * GEODE-676
> * GEODE-677
> If possible, test cleanup should also try to resolve the flakiness in these 
> tests.



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

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

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2599:


Commit 2e2992ac1eb2e9539300dcc0d33918e41d7f6a86 in geode's branch 
refs/heads/feature/GEODE-2420 from [~khowe]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=2e2992a ]

GEODE-2599: fix for "null" in string of dots

Check for string "null" in server/locator status message

Refactor server and locator launcer wait loops by using Process.isAlive
instead of Process.exitValue


> `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: Kenneth Howe
>Priority: Minor
>  Labels: gfsh
> Fix For: 1.2.0
>
>
> {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)

[jira] [Commented] (GEODE-2674) Lucene index is out of sync with data region due to retried event

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2674:


Commit 94eaca7c62d970f085e8457e39b7912885637c7d in geode's branch 
refs/heads/feature/GEODE-2420 from [~upthewaterspout]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=94eaca7 ]

GEODE-2674: Changing the lucene listener to fetch the value from the region

Rather than use the value that is in the queue, use the latest value
from the region to update the lucene index.

This ensures that even if the queue contains spurious events due to
retries or other issues, we put the correct value in the index.

This also potentially saves memory and disk space for the queue, because
the queue does not need to hold the value for the entry.


> Lucene index is out of sync with data region due to retried event
> -
>
> Key: GEODE-2674
> URL: https://issues.apache.org/jira/browse/GEODE-2674
> Project: Geode
>  Issue Type: Bug
>Reporter: Dan Smith
>Assignee: Dan Smith
> Fix For: 1.2.0
>
>
> We're seeing issues where the data in the lucene index does not match the 
> data in a region. Here's what I see happening
> # An accessor starts doing a put
> # The put goes to the current primary
> # Primary distributes the put to the secondary
> # Primary closes it's cache
> # New primary does a destroy on the same entry
> # The accessor retries the put because the old primary closed the cache
> # The retried put is added to the queue, after the destroy. But it is not 
> added to the region, because the region detects that it is a retry.
> # The lucene index applies the put. Now there is an extra entry in the index 
> that is not in the region.



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

[jira] [Commented] (GEODE-2641) export logs help strings has [--group=value(nullvalue)*] [--member=value(nullvalue)*]

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2641:


Commit e46400df3edc286f355fec39258ea5fdbc665127 in geode's branch 
refs/heads/feature/GEODE-2420 from [~jinmeiliao]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=e46400d ]

GEODE-2641: minor help string changes


> export logs help strings has [--group=value(nullvalue)*] 
> [--member=value(nullvalue)*] 
> --
>
> Key: GEODE-2641
> URL: https://issues.apache.org/jira/browse/GEODE-2641
> Project: Geode
>  Issue Type: Bug
>Reporter: Jinmei Liao
>
> export logs help strings has [--group=value(nullvalue)*] 
> [--member=value(nullvalue)*] 
> Also, merge-log option is deprecated, need to say that in the help



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

[jira] [Commented] (GEODE-2655) DUnit to test Lucene Indexing on mixed objects in a region

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2655:


Commit fca17e56f5f8b13ef1665b5211622089a55c29e4 in geode's branch 
refs/heads/feature/GEODE-2420 from [~nnag]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=fca17e5 ]

GEODE-2655: Added DUnit tests for lucene indexes on mixed objects.

* Lucene must be able to index on the common field name of mixed objects
* Lucene indexes must also work when there are mixed objects with no 
common field names.
* Lucene indexes work with different objects, different data type, but 
same field name.

This closes #424


> DUnit to test Lucene Indexing on mixed objects in a region 
> ---
>
> Key: GEODE-2655
> URL: https://issues.apache.org/jira/browse/GEODE-2655
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: nabarun
> Fix For: 1.2.0
>
>
> Testing Lucene indexes when 
> 1. Objects in regions are different but they have same field name.
> 2. Objects are present but they may not have same field names.



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

[jira] [Commented] (GEODE-2522) Refactor Lucene D Unit tests

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2522:


Commit 1e806c69c0060faa5bcbbb53511d12774421d71b in geode's branch 
refs/heads/feature/GEODE-2420 from [~huynhja]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=1e806c6 ]

GEODE-2522: Added missing teardown method in test


> Refactor Lucene D Unit tests
> 
>
> Key: GEODE-2522
> URL: https://issues.apache.org/jira/browse/GEODE-2522
> Project: Geode
>  Issue Type: Improvement
>  Components: lucene
>Reporter: Jason Huynh
>Assignee: Jason Huynh
> Fix For: 1.2.0
>
>
> Currently our dunit tests for lucene are organized as a tree heirarchy based 
> on region types.  This makes it difficult to add a tests for a specific type 
> of region type as other test files can possibly extend the file we add the 
> test to.
> Instead we can use parameterized tests and flatten the heirarchy.



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

[jira] [Commented] (GEODE-2536) DiskId code confusing in how it implements needsToBeWritten

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2536:


Commit 26700b5d0df5468d58acbde6f82ca331544c760f in geode's branch 
refs/heads/feature/GEODE-2420 from [~eshu]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=26700b5 ]

GEODE-2536: Remove the inappropriate implementation of methods in DiskId for 
persistent regions.

markForWriting and unmarkForWriting should not be used for persistent region.
needsToBeWritten always return false now for persistent region, as the 
diskEntry either is being written to disk (sync) or sheduled to be written to 
disk (async)


> DiskId code confusing in how it implements needsToBeWritten
> ---
>
> Key: GEODE-2536
> URL: https://issues.apache.org/jira/browse/GEODE-2536
> Project: Geode
>  Issue Type: Improvement
>  Components: persistence
>Reporter: Darrel Schneider
>Assignee: Eric Shu
>
> DiskId has an abstract method "needsToBeWritten." It is set to true by 
> "markForWriting" and set to false by "unmarkForWriting." DiskId has two types 
> of implementations: one for overflow only regions and one for persistent 
> regions.
> The needsToBeWritten only makes sense for overflow only. But the persistent 
> DiskIds also implement these methods and do so in a way that can be confused 
> with "isKeyIdNegative."
> Since markForWriting will only be called for overflow only disk ids I 
> recommend that the persistent implementation of this method be changed to 
> always throw an exception.
> unmarkForWriting may be called on any type of disk id but for persistent ones 
> should be changed to do nothing.
> needsToBeWritten should be changed to always return false for persistent 
> DiskIds since they are immediately written to disk (or scheduled to be 
> written if async) by whoever gives them a new value. needsToBeWritten is only 
> called by the overflowToDisk method and for a persistent+overflow region it 
> should never need to write the value to disk; all it needs to do is remove 
> the value from memory since it is written to disk.
> The current implementation of these methods on persistent DiskIds do it by 
> negating the keyId. Unfortunately this is also done to indicate that the 
> value was not recovered from disk.



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

[jira] [Assigned] (GEODE-2686) Remove JarClassLoader

[Jared Stewart (JIRA)]

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

Jared Stewart reassigned GEODE-2686:


Assignee: Jared Stewart

> Remove JarClassLoader
> -
>
> Key: GEODE-2686
> URL: https://issues.apache.org/jira/browse/GEODE-2686
> Project: Geode
>  Issue Type: Sub-task
>  Components: management
>Reporter: Jared Stewart
>Assignee: Jared Stewart
>
> Before we can limit the scanning of deployed jars, we need to extricate 
> JarClassLoader, as its implementation eagerly loads all classes into memory.



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

[jira] [Comment Edited] (GEODE-2517) Data transfer of size > 2GB from server to client results in a hang and eventual timeout exception

[nabarun (JIRA)]

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

nabarun edited comment on GEODE-2517 at 3/17/17 8:25 PM:
-

[~bschuchardt] I simply created a dummy class with a string city and also 
filled it with arrays of integers, etc. lot of garbage data to increase the 
size. it was a trial and error situation where I kept incrementing the garbage 
data until i hit the error.
[~hitesh.khamesra] No , i did not set any system properties. 


was (Author: nnag):
[~bschuchardt] I simply created a dummy class with a string city and also 
filled it with arrays of integers, etc. lot of garbage data to increase the 
size. it was a trial an error situation where I kept incrementing the garbage 
data until i hit the error.
[~hitesh.khamesra] No , i did not set any system properties. 

> Data transfer of size > 2GB from server to client results in a hang and 
> eventual timeout exception
> --
>
> Key: GEODE-2517
> URL: https://issues.apache.org/jira/browse/GEODE-2517
> Project: Geode
>  Issue Type: Bug
>  Components: client/server, docs
>Affects Versions: 1.1.0
>Reporter: nabarun
>
> *Situation*:
> 1. Create a server and client.
> 2. Fill the server with a large amount of data. 
> 3. Create a query that will result in over 600,000 entries as result.
> 4. Chunk the result set in such a way that one chunk will result in a size 
> greater than 2GB
> 5. Execute the query from the client.
> *Expected*:
> Message too large exception.
> *Cause / Fix for the issue*:
> If the number of parts to be transmitted is one then in sendBytes()
> {code:title=Message.java}
> for (int i = 0; i < this.numberOfParts; i++) {
>   Part part = this.partsList[i];
>   headerLen += PART_HEADER_SIZE;
>   totalPartLen += part.getLength();
> }
> {code}
> * Here the part.getLength() is an int, so if the size is greater than 2GB we 
> have already overflowed the int barrier and we are putting a negative value 
> in totalPartLen
> so when we do the below check :
> {code:title=Message.java}
> if ((headerLen + totalPartLen) > Integer.MAX_VALUE) {
>   throw new MessageTooLargeException(
>   "Message size (" + (headerLen + totalPartLen) + ") exceeds 
> maximum integer value");
> }
> {code}
> The comparison is between a negative number and positive number 
> [Integer.MAX_VALUE] hence it will always skip this loop.
> and ultimately result in this exception.
> {noformat}
> java.io.IOException: Part length ( -508,098,123 ) and number of parts ( 1 ) 
> inconsistent
>   at 
> com.gemstone.gemfire.internal.cache.tier.sockets.Message.readPayloadFields(Message.java:836)
>   at 
> com.gemstone.gemfire.internal.cache.tier.sockets.ChunkedMessage.readChunk(ChunkedMessage.java:276)
>   at 
> com.gemstone.gemfire.internal.cache.tier.sockets.ChunkedMessage.receiveChunk(ChunkedMessage.java:220)
>   at 
> com.gemstone.gemfire.cache.client.internal.ExecuteRegionFunctionOp$ExecuteRegionFunctionOpImpl.processResponse(ExecuteRegionFunctionOp.java:482)
>   at 
> com.gemstone.gemfire.cache.client.internal.AbstractOp.processResponse(AbstractOp.java:215)
>   at 
> com.gemstone.gemfire.cache.client.internal.AbstractOp.attemptReadResponse(AbstractOp.java:153)
>   at 
> com.gemstone.gemfire.cache.client.internal.AbstractOp.attempt(AbstractOp.java:369)
>   at 
> com.gemstone.gemfire.cache.client.internal.ConnectionImpl.execute(ConnectionImpl.java:252)
>   at 
> com.gemstone.gemfire.cache.client.internal.pooling.PooledConnection.execute(PooledConnection.java:319)
>   at 
> com.gemstone.gemfire.cache.client.internal.OpExecutorImpl.executeWithPossibleReAuthentication(OpExecutorImpl.java:933)
>   at 
> com.gemstone.gemfire.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:158)
>   at 
> com.gemstone.gemfire.cache.client.internal.PoolImpl.execute(PoolImpl.java:716)
>   at 
> com.gemstone.gemfire.cache.client.internal.ExecuteRegionFunctionOp.execute(ExecuteRegionFunctionOp.java:159)
>   at 
> com.gemstone.gemfire.cache.client.internal.ServerRegionProxy.executeFunction(ServerRegionProxy.java:801)
>   at 
> com.gemstone.gemfire.internal.cache.execute.ServerRegionFunctionExecutor.executeOnServer(ServerRegionFunctionExecutor.java:212)
>   at 
> com.gemstone.gemfire.internal.cache.execute.ServerRegionFunctionExecutor.executeFunction(ServerRegionFunctionExecutor.java:165)
>   at 
> com.gemstone.gemfire.internal.cache.execute.ServerRegionFunctionExecutor.execute(ServerRegionFunctionExecutor.java:363)
>   at com.bookshop.buslogic.TestClient.run(TestClient.java:40)
>   at com.bookshop.buslogic.TestClient.main(TestC

[jira] [Assigned] (GEODE-1775) CI failure: ParallelWANPropagationClientServerDUnitTest.testParallelPropagationWithClientServer

[Dan Smith (JIRA)]

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

Dan Smith reassigned GEODE-1775:


Assignee: Dan Smith  (was: Kirk Lund)

> CI failure: 
> ParallelWANPropagationClientServerDUnitTest.testParallelPropagationWithClientServer
> ---
>
> Key: GEODE-1775
> URL: https://issues.apache.org/jira/browse/GEODE-1775
> Project: Geode
>  Issue Type: Bug
>  Components: wan
>Reporter: Grace Meilen
>Assignee: Dan Smith
>  Labels: ci, flaky
>
> {no format}
> :geode-wan:distributedTest
> com.gemstone.gemfire.internal.cache.wan.parallel.ParallelWANPropagationClientServerDUnitTest
>  > testParallelPropagationWithClientServer FAILED
> com.gemstone.gemfire.test.dunit.RMIException: While invoking 
> com.gemstone.gemfire.internal.cache.wan.parallel.ParallelWANPropagationClientServerDUnitTest$$Lambda$19/1746236140.run
>  in VM 4 running on Host 9ff79c8190b7 with 8 VMs
> at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:389)
> at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:355)
> at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:293)
> at 
> com.gemstone.gemfire.internal.cache.wan.parallel.ParallelWANPropagationClientServerDUnitTest.testParallelPropagationWithClientServer(ParallelWANPropagationClientServerDUnitTest.java:59)
> Caused by:
> com.gemstone.gemfire.cache.NoSubscriptionServersAvailableException: 
> com.gemstone.gemfire.cache.NoSubscriptionServersAvailableException: Primary 
> discovery failed.
> at 
> com.gemstone.gemfire.cache.client.internal.QueueManagerImpl.getAllConnections(QueueManagerImpl.java:198)
> at 
> com.gemstone.gemfire.cache.client.internal.OpExecutorImpl.executeOnQueuesAndReturnPrimaryResult(OpExecutorImpl.java:550)
> at 
> com.gemstone.gemfire.cache.client.internal.PoolImpl.executeOnQueuesAndReturnPrimaryResult(PoolImpl.java:763)
> at 
> com.gemstone.gemfire.cache.client.internal.RegisterInterestOp.execute(RegisterInterestOp.java:63)
> at 
> com.gemstone.gemfire.cache.client.internal.ServerRegionProxy.registerInterest(ServerRegionProxy.java:376)
> at 
> com.gemstone.gemfire.internal.cache.LocalRegion.processSingleInterest(LocalRegion.java:3968)
> at 
> com.gemstone.gemfire.internal.cache.LocalRegion.registerInterest(LocalRegion.java:4058)
> at 
> com.gemstone.gemfire.internal.cache.LocalRegion.registerInterest(LocalRegion.java:3873)
> at 
> com.gemstone.gemfire.internal.cache.LocalRegion.registerInterest(LocalRegion.java:3867)
> at 
> com.gemstone.gemfire.internal.cache.LocalRegion.registerInterest(LocalRegion.java:3863)
> at 
> com.gemstone.gemfire.internal.cache.wan.WANTestBase.createClientWithLocator(WANTestBase.java:2154)
> at 
> com.gemstone.gemfire.internal.cache.wan.parallel.ParallelWANPropagationClientServerDUnitTest.lambda$testParallelPropagationWithClientServer$cb73cba9$3(ParallelWANPropagationClientServerDUnitTest.java:59)
> Caused by:
> 
> com.gemstone.gemfire.cache.NoSubscriptionServersAvailableException: Primary 
> discovery failed.
> {no format}



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

[jira] [Updated] (GEODE-1775) CI failure: ParallelWANPropagationClientServerDUnitTest.testParallelPropagationWithClientServer

[Dan Smith (JIRA)]

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

Dan Smith updated GEODE-1775:
-
Component/s: (was: tests)

> CI failure: 
> ParallelWANPropagationClientServerDUnitTest.testParallelPropagationWithClientServer
> ---
>
> Key: GEODE-1775
> URL: https://issues.apache.org/jira/browse/GEODE-1775
> Project: Geode
>  Issue Type: Bug
>  Components: wan
>Reporter: Grace Meilen
>Assignee: Kirk Lund
>  Labels: ci, flaky
>
> {no format}
> :geode-wan:distributedTest
> com.gemstone.gemfire.internal.cache.wan.parallel.ParallelWANPropagationClientServerDUnitTest
>  > testParallelPropagationWithClientServer FAILED
> com.gemstone.gemfire.test.dunit.RMIException: While invoking 
> com.gemstone.gemfire.internal.cache.wan.parallel.ParallelWANPropagationClientServerDUnitTest$$Lambda$19/1746236140.run
>  in VM 4 running on Host 9ff79c8190b7 with 8 VMs
> at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:389)
> at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:355)
> at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:293)
> at 
> com.gemstone.gemfire.internal.cache.wan.parallel.ParallelWANPropagationClientServerDUnitTest.testParallelPropagationWithClientServer(ParallelWANPropagationClientServerDUnitTest.java:59)
> Caused by:
> com.gemstone.gemfire.cache.NoSubscriptionServersAvailableException: 
> com.gemstone.gemfire.cache.NoSubscriptionServersAvailableException: Primary 
> discovery failed.
> at 
> com.gemstone.gemfire.cache.client.internal.QueueManagerImpl.getAllConnections(QueueManagerImpl.java:198)
> at 
> com.gemstone.gemfire.cache.client.internal.OpExecutorImpl.executeOnQueuesAndReturnPrimaryResult(OpExecutorImpl.java:550)
> at 
> com.gemstone.gemfire.cache.client.internal.PoolImpl.executeOnQueuesAndReturnPrimaryResult(PoolImpl.java:763)
> at 
> com.gemstone.gemfire.cache.client.internal.RegisterInterestOp.execute(RegisterInterestOp.java:63)
> at 
> com.gemstone.gemfire.cache.client.internal.ServerRegionProxy.registerInterest(ServerRegionProxy.java:376)
> at 
> com.gemstone.gemfire.internal.cache.LocalRegion.processSingleInterest(LocalRegion.java:3968)
> at 
> com.gemstone.gemfire.internal.cache.LocalRegion.registerInterest(LocalRegion.java:4058)
> at 
> com.gemstone.gemfire.internal.cache.LocalRegion.registerInterest(LocalRegion.java:3873)
> at 
> com.gemstone.gemfire.internal.cache.LocalRegion.registerInterest(LocalRegion.java:3867)
> at 
> com.gemstone.gemfire.internal.cache.LocalRegion.registerInterest(LocalRegion.java:3863)
> at 
> com.gemstone.gemfire.internal.cache.wan.WANTestBase.createClientWithLocator(WANTestBase.java:2154)
> at 
> com.gemstone.gemfire.internal.cache.wan.parallel.ParallelWANPropagationClientServerDUnitTest.lambda$testParallelPropagationWithClientServer$cb73cba9$3(ParallelWANPropagationClientServerDUnitTest.java:59)
> Caused by:
> 
> com.gemstone.gemfire.cache.NoSubscriptionServersAvailableException: Primary 
> discovery failed.
> {no format}



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

[GitHub] geode-native pull request #59: GEODE-2513 Unbrand Function Execution section...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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=15930660#comment-15930660
 ] 

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

Github user asfgit closed the pull request at:

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


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

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

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2513:


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

GEODE-2513 Unbrand Function Execution section of docs


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

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

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2513:


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

GEODE-2513 Unbrand Function Execution section (revision)


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

[jira] [Issue Comment Deleted] (GEODE-2683) Lucene query did not match region values

[xiaojian zhou (JIRA)]

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

xiaojian zhou updated GEODE-2683:
-
Comment: was deleted

(was: GEM-1231)

> Lucene query did not match region values
> 
>
> Key: GEODE-2683
> URL: https://issues.apache.org/jira/browse/GEODE-2683
> Project: Geode
>  Issue Type: Bug
>Reporter: xiaojian zhou
>Assignee: xiaojian zhou
> Fix For: 1.2.0
>
>
> There're several root causes. This one is due to the fix in #45782 changed 
> the order to notify primary bucket's gateway before distribute to secondary. 



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

[jira] [Updated] (GEODE-2683) Lucene query did not match region values

[xiaojian zhou (JIRA)]

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

xiaojian zhou updated GEODE-2683:
-
Description: 
There're several root causes. This one is due to the fix in #45782 changed the 
order to notify primary bucket's gateway before distribute to secondary. 

The log is at /export/buglogs_bvt/xzhou/lucene/concParRegHA-0209-235804
CLIENT vm_1_thr_17_dataStore1_ip-10-32-108-36_11189
TASK[1] parReg.ParRegTest.HydraTask_HADoEntryOps
ERROR util.TestException: util.TestException: Lucene query did not match region 
values. missingKeys=[], extraKeys=[Object_13, Object_17, Object_952, 
Object_550, Object_1876, Object_2732, Object_270, Object_4722, Object_4726, 
Object_2537]
at lucene.LuceneHelper.verifyLuceneIndex(LuceneHelper.java:88)
at lucene.LuceneTest.verifyLuceneIndex(LuceneTest.java:128)
at lucene.LuceneTest.verifyFromSnapshotOnly(LuceneTest.java:79)
at parReg.ParRegTest.verifyFromSnapshot(ParRegTest.java:5638)
at parReg.ParRegTest.concVerify(ParRegTest.java:6035)
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 util.MethodCoordinator.executeOnce(MethodCoordinator.java:68)
at parReg.ParRegTest.HADoEntryOps(ParRegTest.java:2273)
at parReg.ParRegTest.HydraTask_HADoEntryOps(ParRegTest.java:1032)
at sun.reflect.GeneratedMethodAccessor24.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)

The root cause is:
T1: A putAll (or removeAll. operation arrived at primary bucket at memberA
T2: BR.virtualPut() called handleWANEvent() and create shadow key
T3: PutAll will invoke callback (i.e. write into AEQ) before distribution. 
(Put/Destroy will not have this problem because they distribute before callback)
T4: handleSuccessfulBatchDispatch will send ParallelQueueRemovalMessage to the 
secondary bucket at memberB
T5: memberB has dataRegion's secondary bucket, but brq is not created yet (due 
to rebalance). So in ParallelQueueRemovalMessage.process(), it will only try to 
remove the event from tempQueue (which does not contain the event, so it will 
do nothing)
T6: Now, finally the BR.virtualPut()'s distribution arrived at user region's 
secondary bucket at memberB. It will be added into the AEQ (or tempQueue, 
depends). 
T7: memberB becomes new primary (due to rebalance) and re-dispatch the shadow 
key (which has been processed much earlier in memberA). Data mismatch is 
because the replayed event overrides a newer event.

  was:There're several root causes. This one is due to the fix in #45782 
changed the order to notify primary bucket's gateway before distribute to 
secondary. 


> Lucene query did not match region values
> 
>
> Key: GEODE-2683
> URL: https://issues.apache.org/jira/browse/GEODE-2683
> Project: Geode
>  Issue Type: Bug
>Reporter: xiaojian zhou
>Assignee: xiaojian zhou
> Fix For: 1.2.0
>
>
> There're several root causes. This one is due to the fix in #45782 changed 
> the order to notify primary bucket's gateway before distribute to secondary. 
> The log is at /export/buglogs_bvt/xzhou/lucene/concParRegHA-0209-235804
> CLIENT vm_1_thr_17_dataStore1_ip-10-32-108-36_11189
> TASK[1] parReg.ParRegTest.HydraTask_HADoEntryOps
> ERROR util.TestException: util.TestException: Lucene query did not match 
> region values. missingKeys=[], extraKeys=[Object_13, Object_17, Object_952, 
> Object_550, Object_1876, Object_2732, Object_270, Object_4722, Object_4726, 
> Object_2537]
> at lucene.LuceneHelper.verifyLuceneIndex(LuceneHelper.java:88)
> at lucene.LuceneTest.verifyLuceneIndex(LuceneTest.java:128)
> at lucene.LuceneTest.verifyFromSnapshotOnly(LuceneTest.java:79)
> at parReg.ParRegTest.verifyFromSnapshot(ParRegTest.java:5638)
> at parReg.ParRegTest.concVerify(ParRegTest.java:6035)
> 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 util.MethodCoordinator.executeOnce(MethodCoordinator.java:68)
> at parReg.ParRegTest.HADoEntryOps(ParRegTest.java:2273)
> at parReg.ParRegTest.HydraTask_HADoEntryOps(ParRegTest.java:1032)
> at sun.reflect.GeneratedMethodAccessor24.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> The root cause is:
> T1: A putAll (or removeAll. operation 

[jira] [Commented] (GEODE-2521) geode native docs: Document installation from source

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2521:


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

GEODE-2521 geode native docs: Document installation from source


> geode native docs: Document installation from source
> 
>
> Key: GEODE-2521
> URL: https://issues.apache.org/jira/browse/GEODE-2521
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Dave Barnes
>Assignee: Dave Barnes
>
> Update installation instructions to include building from source. Binary 
> distributions will also (presumably) be available on the website's Releases 
> page. (See the installation section of the Geode user manual for a model to 
> follow.)



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

[jira] [Commented] (GEODE-2521) geode native docs: Document installation from source

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2521:


Commit 2ec263b7f7155af6fea2fa977ce957e09971d222 in geode-native's branch 
refs/heads/develop from [~dbarnes97]
[ https://git-wip-us.apache.org/repos/asf?p=geode-native.git;h=2ec263b ]

GEODE-2521 geode native docs: update Windows requirements


> geode native docs: Document installation from source
> 
>
> Key: GEODE-2521
> URL: https://issues.apache.org/jira/browse/GEODE-2521
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Dave Barnes
>Assignee: Dave Barnes
>
> Update installation instructions to include building from source. Binary 
> distributions will also (presumably) be available on the website's Releases 
> page. (See the installation section of the Geode user manual for a model to 
> follow.)



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

[GitHub] geode-native pull request #60: GEODE-2521 geode native docs: Document instal...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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-2521) geode native docs: Document installation from source

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2521:


Commit 6eb93f686ebc031b063128268df867f1c8d93e5d in geode-native's branch 
refs/heads/develop from [~dbarnes97]
[ https://git-wip-us.apache.org/repos/asf?p=geode-native.git;h=6eb93f6 ]

Merge commit '2ec263b7f7155af6fea2fa977ce957e09971d222' into develop

* commit '2ec263b7f7155af6fea2fa977ce957e09971d222':
  GEODE-2521 geode native docs: Document installation from source
  This closes #60


> geode native docs: Document installation from source
> 
>
> Key: GEODE-2521
> URL: https://issues.apache.org/jira/browse/GEODE-2521
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Dave Barnes
>Assignee: Dave Barnes
>
> Update installation instructions to include building from source. Binary 
> distributions will also (presumably) be available on the website's Releases 
> page. (See the installation section of the Geode user manual for a model to 
> follow.)



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

[jira] [Commented] (GEODE-2521) geode native docs: Document installation from source

[ASF GitHub Bot (JIRA)]

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

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

Github user asfgit closed the pull request at:

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


> geode native docs: Document installation from source
> 
>
> Key: GEODE-2521
> URL: https://issues.apache.org/jira/browse/GEODE-2521
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Dave Barnes
>Assignee: Dave Barnes
>
> Update installation instructions to include building from source. Binary 
> distributions will also (presumably) be available on the website's Releases 
> page. (See the installation section of the Geode user manual for a model to 
> follow.)



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

[GitHub] geode pull request #429: Geode-2686

[jaredjstewart]

GitHub user jaredjstewart opened a pull request:

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

Geode-2686

GEODE-2686: Remove JarClassLoader  …
 - Remove JarClassLoader
 - Replace ClassPathLoader's collection of JarClassLoaders with a single 
URLClassLoader
 - Change naming scheme for deployed jars from 'vf.gf#myJar.jar#1' to 
'myJar.v1.jar'

Change singleton implementation of ClassPathLoader from AtomicReference to 
volatile

JarDeployer is threadsafe

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

$ git pull https://github.com/jaredjstewart/geode GEODE-2686

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

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


commit 7788dba702a58e2c3997b974badd8e45e861b47f
Author: Jared Stewart 
Date:   2017-01-19T20:00:04Z

GEODE-2686: Remove JarClassLoader

 - Remove JarClassLoader
 - Replace ClassPathLoader's collection of JarClassLoaders with a single 
URLClassLoader
 - Change naming scheme for deployed jars from 'vf.gf#myJar.jar#1' to 
'myJar.v1.jar'

commit b9e511262b853e6f7ae346eb414138813c0e7a2d
Author: Jared Stewart 
Date:   2017-03-17T00:22:59Z

Change singleton implementation of ClassPathLoader from AtomicReference to 
volatile

commit 5d50b12cc389293246545f08608663df9f962419
Author: Jared Stewart 
Date:   2017-03-17T20:59:32Z

JarDeployer is threadsafe




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

[GitHub] geode issue #429: Geode-2686

[jaredjstewart]

Github user jaredjstewart commented on the issue:

https://github.com/apache/geode/pull/429
  
Precheckin is started (still running)


---
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-2686) Remove JarClassLoader

[ASF GitHub Bot (JIRA)]

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

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

GitHub user jaredjstewart opened a pull request:

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

Geode-2686

GEODE-2686: Remove JarClassLoader  …
 - Remove JarClassLoader
 - Replace ClassPathLoader's collection of JarClassLoaders with a single 
URLClassLoader
 - Change naming scheme for deployed jars from 'vf.gf#myJar.jar#1' to 
'myJar.v1.jar'

Change singleton implementation of ClassPathLoader from AtomicReference to 
volatile

JarDeployer is threadsafe

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

$ git pull https://github.com/jaredjstewart/geode GEODE-2686

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

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


commit 7788dba702a58e2c3997b974badd8e45e861b47f
Author: Jared Stewart 
Date:   2017-01-19T20:00:04Z

GEODE-2686: Remove JarClassLoader

 - Remove JarClassLoader
 - Replace ClassPathLoader's collection of JarClassLoaders with a single 
URLClassLoader
 - Change naming scheme for deployed jars from 'vf.gf#myJar.jar#1' to 
'myJar.v1.jar'

commit b9e511262b853e6f7ae346eb414138813c0e7a2d
Author: Jared Stewart 
Date:   2017-03-17T00:22:59Z

Change singleton implementation of ClassPathLoader from AtomicReference to 
volatile

commit 5d50b12cc389293246545f08608663df9f962419
Author: Jared Stewart 
Date:   2017-03-17T20:59:32Z

JarDeployer is threadsafe




> Remove JarClassLoader
> -
>
> Key: GEODE-2686
> URL: https://issues.apache.org/jira/browse/GEODE-2686
> Project: Geode
>  Issue Type: Sub-task
>  Components: management
>Reporter: Jared Stewart
>Assignee: Jared Stewart
>
> Before we can limit the scanning of deployed jars, we need to extricate 
> JarClassLoader, as its implementation eagerly loads all classes into memory.



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

[jira] [Created] (GEODE-2687) create a test for failed SSL auth

[Ernest Burghardt (JIRA)]

Ernest Burghardt created GEODE-2687:
---

 Summary: create a test for failed SSL auth
 Key: GEODE-2687
 URL: https://issues.apache.org/jira/browse/GEODE-2687
 Project: Geode
  Issue Type: Test
  Components: native client
Reporter: Ernest Burghardt






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

[jira] [Commented] (GEODE-2683) Lucene query did not match region values

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2683:


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

GEODE-2683: let BR.putAll/removeAll to distribute before notify gateway, which
is the same order as put/destroy


> Lucene query did not match region values
> 
>
> Key: GEODE-2683
> URL: https://issues.apache.org/jira/browse/GEODE-2683
> Project: Geode
>  Issue Type: Bug
>Reporter: xiaojian zhou
>Assignee: xiaojian zhou
> Fix For: 1.2.0
>
>
> There're several root causes. This one is due to the fix in #45782 changed 
> the order to notify primary bucket's gateway before distribute to secondary. 
> The log is at /export/buglogs_bvt/xzhou/lucene/concParRegHA-0209-235804
> CLIENT vm_1_thr_17_dataStore1_ip-10-32-108-36_11189
> TASK[1] parReg.ParRegTest.HydraTask_HADoEntryOps
> ERROR util.TestException: util.TestException: Lucene query did not match 
> region values. missingKeys=[], extraKeys=[Object_13, Object_17, Object_952, 
> Object_550, Object_1876, Object_2732, Object_270, Object_4722, Object_4726, 
> Object_2537]
> at lucene.LuceneHelper.verifyLuceneIndex(LuceneHelper.java:88)
> at lucene.LuceneTest.verifyLuceneIndex(LuceneTest.java:128)
> at lucene.LuceneTest.verifyFromSnapshotOnly(LuceneTest.java:79)
> at parReg.ParRegTest.verifyFromSnapshot(ParRegTest.java:5638)
> at parReg.ParRegTest.concVerify(ParRegTest.java:6035)
> 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 util.MethodCoordinator.executeOnce(MethodCoordinator.java:68)
> at parReg.ParRegTest.HADoEntryOps(ParRegTest.java:2273)
> at parReg.ParRegTest.HydraTask_HADoEntryOps(ParRegTest.java:1032)
> at sun.reflect.GeneratedMethodAccessor24.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> The root cause is:
> T1: A putAll (or removeAll. operation arrived at primary bucket at memberA
> T2: BR.virtualPut() called handleWANEvent() and create shadow key
> T3: PutAll will invoke callback (i.e. write into AEQ) before distribution. 
> (Put/Destroy will not have this problem because they distribute before 
> callback)
> T4: handleSuccessfulBatchDispatch will send ParallelQueueRemovalMessage to 
> the secondary bucket at memberB
> T5: memberB has dataRegion's secondary bucket, but brq is not created yet 
> (due to rebalance). So in ParallelQueueRemovalMessage.process(), it will only 
> try to remove the event from tempQueue (which does not contain the event, so 
> it will do nothing)
> T6: Now, finally the BR.virtualPut()'s distribution arrived at user region's 
> secondary bucket at memberB. It will be added into the AEQ (or tempQueue, 
> depends). 
> T7: memberB becomes new primary (due to rebalance) and re-dispatch the shadow 
> key (which has been processed much earlier in memberA). Data mismatch is 
> because the replayed event overrides a newer event.



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

[jira] [Resolved] (GEODE-2683) Lucene query did not match region values

[xiaojian zhou (JIRA)]

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

xiaojian zhou resolved GEODE-2683.
--
Resolution: Fixed

> Lucene query did not match region values
> 
>
> Key: GEODE-2683
> URL: https://issues.apache.org/jira/browse/GEODE-2683
> Project: Geode
>  Issue Type: Bug
>Reporter: xiaojian zhou
>Assignee: xiaojian zhou
> Fix For: 1.2.0
>
>
> There're several root causes. This one is due to the fix in #45782 changed 
> the order to notify primary bucket's gateway before distribute to secondary. 
> The log is at /export/buglogs_bvt/xzhou/lucene/concParRegHA-0209-235804
> CLIENT vm_1_thr_17_dataStore1_ip-10-32-108-36_11189
> TASK[1] parReg.ParRegTest.HydraTask_HADoEntryOps
> ERROR util.TestException: util.TestException: Lucene query did not match 
> region values. missingKeys=[], extraKeys=[Object_13, Object_17, Object_952, 
> Object_550, Object_1876, Object_2732, Object_270, Object_4722, Object_4726, 
> Object_2537]
> at lucene.LuceneHelper.verifyLuceneIndex(LuceneHelper.java:88)
> at lucene.LuceneTest.verifyLuceneIndex(LuceneTest.java:128)
> at lucene.LuceneTest.verifyFromSnapshotOnly(LuceneTest.java:79)
> at parReg.ParRegTest.verifyFromSnapshot(ParRegTest.java:5638)
> at parReg.ParRegTest.concVerify(ParRegTest.java:6035)
> 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 util.MethodCoordinator.executeOnce(MethodCoordinator.java:68)
> at parReg.ParRegTest.HADoEntryOps(ParRegTest.java:2273)
> at parReg.ParRegTest.HydraTask_HADoEntryOps(ParRegTest.java:1032)
> at sun.reflect.GeneratedMethodAccessor24.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> The root cause is:
> T1: A putAll (or removeAll. operation arrived at primary bucket at memberA
> T2: BR.virtualPut() called handleWANEvent() and create shadow key
> T3: PutAll will invoke callback (i.e. write into AEQ) before distribution. 
> (Put/Destroy will not have this problem because they distribute before 
> callback)
> T4: handleSuccessfulBatchDispatch will send ParallelQueueRemovalMessage to 
> the secondary bucket at memberB
> T5: memberB has dataRegion's secondary bucket, but brq is not created yet 
> (due to rebalance). So in ParallelQueueRemovalMessage.process(), it will only 
> try to remove the event from tempQueue (which does not contain the event, so 
> it will do nothing)
> T6: Now, finally the BR.virtualPut()'s distribution arrived at user region's 
> secondary bucket at memberB. It will be added into the AEQ (or tempQueue, 
> depends). 
> T7: memberB becomes new primary (due to rebalance) and re-dispatch the shadow 
> key (which has been processed much earlier in memberA). Data mismatch is 
> because the replayed event overrides a newer event.



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

[GitHub] geode-native pull request #61: GEODE-2687: test for ssl auth failure:

[echobravopapa]

GitHub user echobravopapa opened a pull request:

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

GEODE-2687: test for ssl auth failure:

- Added testThinClientSSLAuthFail to QUICK list.
- removed un-needed test code.
- catching expected exception
- Add test for untrusted server cert

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

$ git pull https://github.com/echobravopapa/geode-native feature/GEODE-2687

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

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


commit 4149cd6dc7f7fa499e0192aee5cd6407b9f73a83
Author: Ernest Burghardt 
Date:   2017-03-17T21:59:24Z

GEODE-2687: test for ssl auth failure:

- Added testThinClientSSLAuthFail to QUICK list.
- removed un-needed test code.
- catching expected exception
- Add test for untrusted server cert




---
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-2687) create a test for failed SSL auth

[ASF GitHub Bot (JIRA)]

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

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

GitHub user echobravopapa opened a pull request:

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

GEODE-2687: test for ssl auth failure:

- Added testThinClientSSLAuthFail to QUICK list.
- removed un-needed test code.
- catching expected exception
- Add test for untrusted server cert

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

$ git pull https://github.com/echobravopapa/geode-native feature/GEODE-2687

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

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


commit 4149cd6dc7f7fa499e0192aee5cd6407b9f73a83
Author: Ernest Burghardt 
Date:   2017-03-17T21:59:24Z

GEODE-2687: test for ssl auth failure:

- Added testThinClientSSLAuthFail to QUICK list.
- removed un-needed test code.
- catching expected exception
- Add test for untrusted server cert




> create a test for failed SSL auth
> -
>
> Key: GEODE-2687
> URL: https://issues.apache.org/jira/browse/GEODE-2687
> Project: Geode
>  Issue Type: Test
>  Components: native client
>Reporter: Ernest Burghardt
>




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

[jira] [Commented] (GEODE-2687) create a test for failed SSL auth

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/geode-native/pull/61#discussion_r106755238
  
--- Diff: src/cppcache/integration-test/CacheHelper.cpp ---
@@ -1812,17 +1812,32 @@ std::string 
CacheHelper::generateGeodeProperties(const std::string& path,
   msg += "enable-network-partition-detection=false\n";
 
   if (ssl) {
-msg += "jmx-manager-ssl-enabled=false\n";
-msg += "cluster-ssl-enabled=true\n";
-msg += "cluster-ssl-require-authentication=true\n";
-msg += "cluster-ssl-ciphers=TLS_RSA_WITH_AES_128_CBC_SHA\n";
-msg += "cluster-ssl-keystore-type=jks\n";
-msg += "cluster-ssl-keystore=" + keystore + "/server_keystore.jks\n";
-msg += "cluster-ssl-keystore-password=gemstone\n";
-msg += "cluster-ssl-truststore=" + keystore + 
"/server_truststore.jks\n";
-msg += "cluster-ssl-truststore-password=gemstone\n";
-msg += "security-username=\n";
-msg += "security-userPassword= \n";
+if (untrustedCert){
--- End diff --

Much like keystore is a parameter to this method, could this if-then-else 
statement be collapsed to a single set of concatenations that use a (possibly 
empty) prefix string, e.g., "untrusted_"?


> create a test for failed SSL auth
> -
>
> Key: GEODE-2687
> URL: https://issues.apache.org/jira/browse/GEODE-2687
> Project: Geode
>  Issue Type: Test
>  Components: native client
>Reporter: Ernest Burghardt
>




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

[GitHub] geode-native pull request #61: GEODE-2687: test for ssl auth failure:

[PivotalSarge]

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

https://github.com/apache/geode-native/pull/61#discussion_r106755238
  
--- Diff: src/cppcache/integration-test/CacheHelper.cpp ---
@@ -1812,17 +1812,32 @@ std::string 
CacheHelper::generateGeodeProperties(const std::string& path,
   msg += "enable-network-partition-detection=false\n";
 
   if (ssl) {
-msg += "jmx-manager-ssl-enabled=false\n";
-msg += "cluster-ssl-enabled=true\n";
-msg += "cluster-ssl-require-authentication=true\n";
-msg += "cluster-ssl-ciphers=TLS_RSA_WITH_AES_128_CBC_SHA\n";
-msg += "cluster-ssl-keystore-type=jks\n";
-msg += "cluster-ssl-keystore=" + keystore + "/server_keystore.jks\n";
-msg += "cluster-ssl-keystore-password=gemstone\n";
-msg += "cluster-ssl-truststore=" + keystore + 
"/server_truststore.jks\n";
-msg += "cluster-ssl-truststore-password=gemstone\n";
-msg += "security-username=\n";
-msg += "security-userPassword= \n";
+if (untrustedCert){
--- End diff --

Much like keystore is a parameter to this method, could this if-then-else 
statement be collapsed to a single set of concatenations that use a (possibly 
empty) prefix string, e.g., "untrusted_"?


---
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] [Resolved] (GEODE-2648) DiskSpaceLimitIntegrationTest.aboveZeroDeletesPreviousFiles fails with TimeoutException

[Kirk Lund (JIRA)]

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

Kirk Lund resolved GEODE-2648.
--
   Resolution: Fixed
Fix Version/s: 1.2.0

> DiskSpaceLimitIntegrationTest.aboveZeroDeletesPreviousFiles fails with 
> TimeoutException
> ---
>
> Key: GEODE-2648
> URL: https://issues.apache.org/jira/browse/GEODE-2648
> Project: Geode
>  Issue Type: Bug
>  Components: statistics, tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>  Labels: Flaky
> Fix For: 1.2.0
>
>
> {noformat}
> java.util.concurrent.TimeoutException: File 
> /tmp/junit460899251228048267/aboveZeroDeletesPreviousFiles-02-01.gfs does not 
> exist after 5559 samples within 1 MINUTES
>   at 
> org.apache.geode.internal.statistics.DiskSpaceLimitIntegrationTest.sampleUntilFileExists(DiskSpaceLimitIntegrationTest.java:285)
>   at 
> org.apache.geode.internal.statistics.DiskSpaceLimitIntegrationTest.aboveZeroDeletesPreviousFiles(DiskSpaceLimitIntegrationTest.java:199)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
>   at org.junit.rules.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.runners.ParentRunner.run(ParentRunner.java:363)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66)
>   at 
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
>   at 
> org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
>   at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
>   at 
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:109)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(Reflec

[jira] [Created] (GEODE-2688) The Lucene xml in the cluster config includes the internal async event queue id

[Barry Oglesby (JIRA)]

Barry Oglesby created GEODE-2688:


 Summary: The Lucene xml in the cluster config includes the 
internal async event queue id
 Key: GEODE-2688
 URL: https://issues.apache.org/jira/browse/GEODE-2688
 Project: Geode
  Issue Type: Bug
  Components: lucene
Reporter: Barry Oglesby


The cluster config xml contains the internal async-event-queue-ids like:
{noformat}

  

  
  http://geode.apache.org/schema/lucene"; 
name="full_index">

  

{noformat}
This is not necessary since the async event id will be added to the 
{{AttributesFactory}} in the {{RegionListener beforeCreate}} call:
{noformat}
java.lang.Exception: Stack trace
at java.lang.Thread.dumpStack(Thread.java:1329)
at 
org.apache.geode.cache.lucene.internal.LuceneServiceImpl.getUniqueIndexName(LuceneServiceImpl.java:127)
at 
org.apache.geode.cache.lucene.internal.LuceneRegionListener.beforeCreate(LuceneRegionListener.java:88)
at 
org.apache.geode.internal.cache.GemFireCacheImpl.invokeRegionBefore(GemFireCacheImpl.java:3363)
at 
org.apache.geode.internal.cache.GemFireCacheImpl.createVMRegion(GemFireCacheImpl.java:3212)
at 
org.apache.geode.internal.cache.GemFireCacheImpl.basicCreateRegion(GemFireCacheImpl.java:3190)
at 
org.apache.geode.internal.cache.GemFireCacheImpl.createRegion(GemFireCacheImpl.java:3178)
at org.apache.geode.cache.RegionFactory.create(RegionFactory.java:762)
at 
org.apache.geode.management.internal.cli.functions.RegionCreateFunction.createRegion(RegionCreateFunction.java:358)
at 
org.apache.geode.management.internal.cli.functions.RegionCreateFunction.execute(RegionCreateFunction.java:93)
at 
org.apache.geode.internal.cache.MemberFunctionStreamingMessage.process(MemberFunctionStreamingMessage.java:191)
at 
org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376)
at 
org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:442)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at 
org.apache.geode.distributed.internal.DistributionManager.runUntilShutdown(DistributionManager.java:621)
at 
org.apache.geode.distributed.internal.DistributionManager$9$1.run(DistributionManager.java:1067)
at java.lang.Thread.run(Thread.java:745)
{noformat}
This is not a huge deal, except in the case where the index is destroyed. The 
_destroy lucene index_ command currently removes just the *lucene:index* from 
the cluster config xml. It doesn't do anything with the 
*async-event-queue-ids*. There would have to be a separate {{XmlEntity}} to 
deal with those, so it would be better if they weren't included in the first 
place.




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

[jira] [Assigned] (GEODE-2657) Execute Region Function sends incorrect message format

[Jacob S. Barrett (JIRA)]

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

Jacob S. Barrett reassigned GEODE-2657:
---

Assignee: Jacob S. Barrett

> Execute Region Function sends incorrect message format
> --
>
> Key: GEODE-2657
> URL: https://issues.apache.org/jira/browse/GEODE-2657
> Project: Geode
>  Issue Type: Bug
>  Components: native client
>Reporter: David Kimura
>Assignee: Jacob S. Barrett
>
> `TcrMessageExecuteRegionFunction` is missing a call to set `m_hasResults`. 
> This causes the message response to be parsed synchronously and not 
> asynchronously chunked. The synchronous parser does not support this message 
> type and it barfs.



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

Review Request 57740: GEODE-2679: Lucene asynchronous disk writes for aeq can lead to data mismatch after compacting

[Jason Huynh]

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

Review request for geode, Lynn Hughes-Godfrey, nabarun nag, and xiaojian zhou.


Repository: geode


Description
---

Forcing disk synchronized flag to true for the Lucene AEQ


Diffs
-

  
geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/LuceneIndexImpl.java
 66dc1f9 


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


Testing
---


Thanks,

Jason Huynh

[jira] [Created] (GEODE-2689) If a region containing a Lucene index is created in one group and altered in another, a member in the other group will fail to start

[Barry Oglesby (JIRA)]

Barry Oglesby created GEODE-2689:


 Summary: If a region containing a Lucene index is created in one 
group and altered in another, a member in the other group will fail to start
 Key: GEODE-2689
 URL: https://issues.apache.org/jira/browse/GEODE-2689
 Project: Geode
  Issue Type: Bug
  Components: lucene
Reporter: Barry Oglesby


Steps to reproduce:

- create lucene index --name=full_index --region=data --field=field1
- create region --name=data --type=PARTITION_REDUNDANT
- alter region --name=data --cache-listener=TestCacheListener --group=group1

At this point, the cluster config xml looks like:
{noformat}
[info 2017/03/15 17:04:17.375 PDT server3  tid=0x1] 
  ***
  Configuration for  'cluster'
  
  Jar files to deployed
  
  http://geode.apache.org/schema/cache"; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; copy-on-read="false" 
is-server="false" lock-lease="120" lock-timeout="60" search-timeout="300" 
version="1.0" xsi:schemaLocation="http://geode.apache.org/schema/cache 
http://geode.apache.org/schema/cache/cache-1.0.xsd";>
  
  

  
  http://geode.apache.org/schema/lucene"; 
name="full_index">

  

  
  
  ***
  Configuration for  'group1'
  
  Jar files to deployed
  
  http://geode.apache.org/schema/cache"; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; copy-on-read="false" 
is-server="false" lock-lease="120" lock-timeout="60" search-timeout="300" 
version="1.0" xsi:schemaLocation="http://geode.apache.org/schema/cache 
http://geode.apache.org/schema/cache/cache-1.0.xsd";>
  
  


  TestCacheListener

  
  http://geode.apache.org/schema/lucene"; 
name="full_index">

  

  
{noformat}
If a member is started in the group (group1 in this case), it will fail to 
start with the following error:
{noformat}
[error 2017/03/15 17:04:19.715 PDT  tid=0x1] Lucene index already exists 
in region

Exception in thread "main" java.lang.IllegalArgumentException: Lucene index 
already exists in region
at 
org.apache.geode.cache.lucene.internal.LuceneServiceImpl.registerDefinedIndex(LuceneServiceImpl.java:201)
at 
org.apache.geode.cache.lucene.internal.LuceneServiceImpl.createIndex(LuceneServiceImpl.java:154)
at 
org.apache.geode.cache.lucene.internal.xml.LuceneIndexCreation.beforeCreate(LuceneIndexCreation.java:85)
at 
org.apache.geode.internal.cache.extension.SimpleExtensionPoint.beforeCreate(SimpleExtensionPoint.java:77)
at 
org.apache.geode.internal.cache.xmlcache.RegionCreation.createRoot(RegionCreation.java:252)
at 
org.apache.geode.internal.cache.xmlcache.CacheCreation.initializeRegions(CacheCreation.java:544)
at 
org.apache.geode.internal.cache.xmlcache.CacheCreation.create(CacheCreation.java:495)
at 
org.apache.geode.internal.cache.xmlcache.CacheXmlParser.create(CacheXmlParser.java:343)
at 
org.apache.geode.internal.cache.GemFireCacheImpl.loadCacheXml(GemFireCacheImpl.java:4479)
at 
org.apache.geode.internal.cache.ClusterConfigurationLoader.applyClusterXmlConfiguration(ClusterConfigurationLoader.java:129)
at 
org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1243)
at 
org.apache.geode.internal.cache.GemFireCacheImpl.basicCreate(GemFireCacheImpl.java:798)
at 
org.apache.geode.internal.cache.GemFireCacheImpl.create(GemFireCacheImpl.java:783)
at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:178)
at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:218)
at TestBase.initializeServerCache(TestBase.java:22)
at TestServer.main(TestServer.java:7)
{noformat}
I made a quick change in {{LuceneIndexCreation beforeCreate}} to just log the 
{{IllegalArgumentException}}. I'm not sure if this is good enough or not.
{noformat}
public void beforeCreate(Extensible> source, Cache cache) {
  LuceneServiceImpl service = (LuceneServiceImpl) 
LuceneServiceProvider.get(cache);
  Analyzer analyzer = this.fieldAnalyzers == null ? new StandardAnalyzer()
: new PerFieldAnalyzerWrapper(new StandardAnalyzer(), this.fieldAnalyzers);
  try {
service.createIndex(getName(), getRegionPath(), analyzer, 
this.fieldAnalyzers,
  getFieldNames());
  } catch (IllegalArgumentException e) {
// log a warning or info here
  }
}
{noformat}
We might want to create a {{LuceneIndexExistsException}} to catch here. We also 
might want to compare the indexes to see that they are the same.

btw - this same test with OQL works:

In the OQL case, the cluster config looks like:
{noformat}
[info 2017/03/15 17:14:12.364 PDT server3  tid=0x1] 
  ***
  Con

[GitHub] geode-native pull request #62: GEODE-2513 Unbrand Connection Pools section o...

[davebarnes97]

GitHub user davebarnes97 opened a pull request:

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

GEODE-2513 Unbrand Connection Pools section of docs



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

$ git pull https://github.com/davebarnes97/geode-native 
feature/GEODE-2513-ConPools

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

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


commit 4c438ddbeadeaa3f3dad734342ecbb8f272f68cd
Author: Dave Barnes 
Date:   2017-03-17T23:06:28Z

GEODE-2513 Unbrand Connection Pools section of docs




---
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=15930918#comment-15930918
 ] 

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

GitHub user davebarnes97 opened a pull request:

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

GEODE-2513 Unbrand Connection Pools section of docs



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

$ git pull https://github.com/davebarnes97/geode-native 
feature/GEODE-2513-ConPools

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

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


commit 4c438ddbeadeaa3f3dad734342ecbb8f272f68cd
Author: Dave Barnes 
Date:   2017-03-17T23:06:28Z

GEODE-2513 Unbrand Connection Pools section of docs




> 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: Review Request 57740: GEODE-2679: Lucene asynchronous disk writes for aeq can lead to data mismatch after compacting

[xiaojian zhou]

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


Ship it!




Ship It!

- xiaojian zhou


On March 17, 2017, 11:41 p.m., Jason Huynh wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/57740/
> ---
> 
> (Updated March 17, 2017, 11:41 p.m.)
> 
> 
> Review request for geode, Lynn Hughes-Godfrey, nabarun nag, and xiaojian zhou.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Forcing disk synchronized flag to true for the Lucene AEQ
> 
> 
> Diffs
> -
> 
>   
> geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/LuceneIndexImpl.java
>  66dc1f9 
> 
> 
> Diff: https://reviews.apache.org/r/57740/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Jason Huynh
> 
>

Build failed in Jenkins: Geode-nightly #779

[Apache Jenkins Server]

See 


Changes:

[upthewaterspout] GEODE-2674: Changing the lucene listener to fetch the value 
from the

[klund] GEODE-2645: rewrite test to fix flakiness and improve readability

[nnag] GEODE-2655: Added DUnit tests for lucene indexes on mixed objects.

[eshu] GEODE-2536: Remove the inappropriate implementation of methods in DiskId

[klund] GEODE-2648: always move deleted files to dirOfDeletedFiles

[upthewaterspout] GEODE-2672: Increase the timeout in LuceneManagementDUnitTest

--
[...truncated 110.93 KB...]
:geode-cq:compileTestJavaNote: Some input files use or override a deprecated 
API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

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

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

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

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

:geode-pulse:processTestResources
:geode-pulse:testClasses
:geode-pulse:checkMissedTests
:geode-pulse:spotlessJavaCheck
:geode-pulse:spotlessCheck
:geode-pulse:test
:geode-pulse:check
:geode-pulse:build
:geode-pulse:distributedTest
:geode-pulse:flakyTest
:geode-pulse:integrationTest
:geode-rebalancer:assemble
:geode-rebalancer:compileTestJava
:geode-rebalancer:processTestResources UP-TO-DATE
:geode-rebalancer:testClasses
:geode-rebalancer:checkMissedTests
:geode-rebalancer:spotlessJavaCheck
:geode-rebalancer:spotlessCheck
:geode-rebalancer:test
:geode-rebalancer:check
:geode-rebalancer:build
:geode-rebalancer:distributedTest
:geode-rebalancer:flakyTest
:geode-rebalancer:integrationTest
:geode-wan:assemble
:geode-wan:compileTestJavaNote: Some input files use or