[jira] [Created] (GEODE-3234) FunctionAccessController's argsInBody is always empty string

[xiaojian zhou (JIRA)]

xiaojian zhou created GEODE-3234:


 Summary: FunctionAccessController's argsInBody is always empty 
string
 Key: GEODE-3234
 URL: https://issues.apache.org/jira/browse/GEODE-3234
 Project: Geode
  Issue Type: Bug
  Components: rest (admin)
Reporter: xiaojian zhou


This field expects a json format, such as { "param":"abc,edf" }, but the 
args[0] got from  jsonToObjectArray(argsInBody) is always an empty string.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (GEODE-3202) Add an example to demonstrate Lucene indexing and searching

[Diane Hardman (JIRA)]

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

Diane Hardman resolved GEODE-3202.
--
   Resolution: Fixed
Fix Version/s: 1.3.0

> Add an example to demonstrate Lucene indexing and searching
> ---
>
> Key: GEODE-3202
> URL: https://issues.apache.org/jira/browse/GEODE-3202
> Project: Geode
>  Issue Type: New Feature
>  Components: lucene
>Reporter: Diane Hardman
>Assignee: Diane Hardman
> Fix For: 1.3.0
>
>
> Create a simple example to demonstrate new Lucene feature.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3233) Examples distribution files need apache prefix

[ASF GitHub Bot (JIRA)]

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

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

GitHub user metatype opened a pull request:

https://github.com/apache/geode-examples/pull/11

GEODE-3233 Prefix distribution files with apache-



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

$ git pull https://github.com/metatype/geode-examples develop

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

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


commit bcf98bc1cc94f0d72a7c3e4192691e3ea01a25e8
Author: Anthony Baker 
Date:   2017-07-18T00:38:59Z

GEODE-3233 Prefix distribution files with apache-




> Examples distribution files need apache prefix
> --
>
> Key: GEODE-3233
> URL: https://issues.apache.org/jira/browse/GEODE-3233
> Project: Geode
>  Issue Type: Bug
>  Components: examples
>Reporter: Anthony Baker
>
> The geode-examples distributions do not include the apache name prefix.  They 
> should be named apache-geode-examples-* for consistency and branding.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3186) CI failure (windows): org.apache.geode.internal.cache.DiskIFJUnitTest.testTwoDiskStores failed with java.lang.RuntimeException: Error deleting file

[Darrel Schneider (JIRA)]

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

Darrel Schneider commented on GEODE-3186:
-

This is a common problem on Windows. If a file is still open then attempts to 
delete the file will fail.
What is hard to tell in this case is when this happened. The failure does not 
have any line numbers.
I think we need to rerun this one by itself in a debugger to figure out what 
code is attempting to remove the .if file.


> CI failure (windows): 
> org.apache.geode.internal.cache.DiskIFJUnitTest.testTwoDiskStores failed with 
> java.lang.RuntimeException: Error deleting file
> ---
>
> Key: GEODE-3186
> URL: https://issues.apache.org/jira/browse/GEODE-3186
> Project: Geode
>  Issue Type: Bug
>  Components: persistence
>Reporter: Lynn Gallinat
>
> {noformat}
> org.apache.geode.internal.cache.DiskIFJUnitTest > testTwoDiskStores FAILED
> java.lang.RuntimeException: Error deleting file 
> testingDirectory\testTwoDiskStores1\BACKUPtestTwoDiskStores.if
> Caused by:
> java.nio.file.FileSystemException: 
> testingDirectory\testTwoDiskStores1\BACKUPtestTwoDiskStores.if: The process 
> cannot access the file because it is being used by another process.{noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3232) Race condition serializing FilterProfile

[ASF GitHub Bot (JIRA)]

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

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

Github user upthewaterspout commented on the issue:

https://github.com/apache/geode/pull/640
  
@ladyVader @nabarunnag 


> Race condition serializing FilterProfile
> 
>
> Key: GEODE-3232
> URL: https://issues.apache.org/jira/browse/GEODE-3232
> Project: Geode
>  Issue Type: Bug
>  Components: client queues
>Reporter: Dan Smith
>
> We saw an error we can't reproduce deserializing a FilterProfile.
> {noformat}
> [severe 2017/07/07 21:31:28.538 PDT 
> bridgegemfire4_rs-myFullRegr-client-23_13409  rs-myFullRegr-client-23(bridgegemfire1_rs-myFullRegr-client-23_13408:13408):1025
>  shared unordered uid=3 port=56290> tid=0x5c] Error deserializing message
> org.apache.geode.SerializationException: Could not create an instance of  
> org.apache.geode.internal.cache.CreateRegionProcessor$CreateRegionReplyMessage
>  .
> at 
> org.apache.geode.internal.InternalDataSerializer.invokeFromData(InternalDataSerializer.java:2381)
> at 
> org.apache.geode.internal.DSFIDFactory.create(DSFIDFactory.java:981)
> at 
> org.apache.geode.internal.InternalDataSerializer.readDSFID(InternalDataSerializer.java:2573)
> at 
> org.apache.geode.internal.tcp.Connection.processNIOBuffer(Connection.java:3530)
> at 
> org.apache.geode.internal.tcp.Connection.runNioReader(Connection.java:1814)
> at org.apache.geode.internal.tcp.Connection.run(Connection.java:1675)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: org.apache.geode.SerializationException: Could not create an 
> instance of  
> org.apache.geode.internal.cache.partitioned.RegionAdvisor$PartitionProfile .
> at 
> org.apache.geode.internal.InternalDataSerializer.invokeFromData(InternalDataSerializer.java:2381)
> at 
> org.apache.geode.internal.DSFIDFactory.create(DSFIDFactory.java:981)
> at 
> org.apache.geode.internal.InternalDataSerializer.basicReadObject(InternalDataSerializer.java:2691)
> at 
> org.apache.geode.DataSerializer.readObject(DataSerializer.java:2961)
> at 
> org.apache.geode.internal.cache.CreateRegionProcessor$CreateRegionReplyMessage.fromData(CreateRegionProcessor.java:798)
> at 
> org.apache.geode.internal.InternalDataSerializer.invokeFromData(InternalDataSerializer.java:2370)
> ... 8 more
> Caused by: org.apache.geode.SerializationException: Could not create an 
> instance of  org.apache.geode.internal.cache.FilterProfile .
> at 
> org.apache.geode.internal.InternalDataSerializer.invokeFromData(InternalDataSerializer.java:2381)
> at 
> org.apache.geode.internal.DSFIDFactory.create(DSFIDFactory.java:981)
> at 
> org.apache.geode.internal.InternalDataSerializer.basicReadObject(InternalDataSerializer.java:2691)
> at 
> org.apache.geode.DataSerializer.readObject(DataSerializer.java:2961)
> at 
> org.apache.geode.internal.cache.CacheDistributionAdvisor$CacheProfile.fromData(CacheDistributionAdvisor.java:867)
> at 
> org.apache.geode.internal.cache.partitioned.RegionAdvisor$PartitionProfile.fromData(RegionAdvisor.java:586)
> at 
> org.apache.geode.internal.InternalDataSerializer.invokeFromData(InternalDataSerializer.java:2370)
> ... 13 more
> Caused by: java.nio.BufferUnderflowException
> at java.nio.Buffer.nextGetIndex(Buffer.java:506)
> at java.nio.DirectByteBuffer.getInt(DirectByteBuffer.java:681)
> at 
> org.apache.geode.internal.tcp.ByteBufferInputStream$ByteBufferByteSource.getInt(ByteBufferInputStream.java:267)
> at 
> org.apache.geode.internal.tcp.ByteBufferInputStream.readInt(ByteBufferInputStream.java:963)
> at 
> org.apache.geode.internal.InternalDataSerializer.readSetOfLongs(InternalDataSerializer.java:1775)
> at 
> org.apache.geode.internal.cache.FilterProfile.fromData(FilterProfile.java:1469)
> at 
> org.apache.geode.internal.InternalDataSerializer.invokeFromData(InternalDataSerializer.java:2370)
> ... 19 more
> {noformat}
> From code inspection ,it looks like FilterProfile stores allKeyClients and 
> some other fields CopyOnWriteHashSets, which makes me think they can be 
> concurrently modified.
> However, FilterProfile.toData does this to write out this hash set.
> {code}
> InternalDataSerializer.writeSetOfLongs(this.allKeyClients, 
> this.clientMap.hasLongID, out);
> {code}
> Within writeSetOfLongs, it first reads the size and writes it to the stream, 
> and then 

[jira] [Commented] (GEODE-3232) Race condition serializing FilterProfile

[ASF GitHub Bot (JIRA)]

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

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

GitHub user upthewaterspout opened a pull request:

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

GEODE-3232: Get a snapshot of maps when serializing FilterProfile

Avoiding a race when serializing a CopyOnWrite data structures be
grabbing a copy first.

Thank you for submitting a contribution to Apache Geode.

In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:

### For all changes:
- [ ] Is there a JIRA ticket associated with this PR? Is it referenced in 
the commit message?

- [ ] Has your PR been rebased against the latest commit within the target 
branch (typically `develop`)?

- [ ] Is your initial contribution a single, squashed commit?

- [ ] Does `gradlew build` run cleanly?

- [ ] Have you written or updated unit tests to verify your changes?

- [ ] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)?

### Note:
Please ensure that once the PR is submitted, you check travis-ci for build 
issues and
submit an update to your PR as soon as possible. If you need help, please 
send an
email to d...@geode.apache.org.


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

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

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

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


commit aaba2aae27c5b4f57d3bfba6220f6dfff60222f0
Author: Dan Smith 
Date:   2017-07-17T23:46:19Z

GEODE-3232: Get a snapshot of maps when serializing FilterProfile

Avoiding a race when serializing a CopyOnWrite data structures be
grabbing a copy first.




> Race condition serializing FilterProfile
> 
>
> Key: GEODE-3232
> URL: https://issues.apache.org/jira/browse/GEODE-3232
> Project: Geode
>  Issue Type: Bug
>  Components: client queues
>Reporter: Dan Smith
>
> We saw an error we can't reproduce deserializing a FilterProfile.
> {noformat}
> [severe 2017/07/07 21:31:28.538 PDT 
> bridgegemfire4_rs-myFullRegr-client-23_13409  rs-myFullRegr-client-23(bridgegemfire1_rs-myFullRegr-client-23_13408:13408):1025
>  shared unordered uid=3 port=56290> tid=0x5c] Error deserializing message
> org.apache.geode.SerializationException: Could not create an instance of  
> org.apache.geode.internal.cache.CreateRegionProcessor$CreateRegionReplyMessage
>  .
> at 
> org.apache.geode.internal.InternalDataSerializer.invokeFromData(InternalDataSerializer.java:2381)
> at 
> org.apache.geode.internal.DSFIDFactory.create(DSFIDFactory.java:981)
> at 
> org.apache.geode.internal.InternalDataSerializer.readDSFID(InternalDataSerializer.java:2573)
> at 
> org.apache.geode.internal.tcp.Connection.processNIOBuffer(Connection.java:3530)
> at 
> org.apache.geode.internal.tcp.Connection.runNioReader(Connection.java:1814)
> at org.apache.geode.internal.tcp.Connection.run(Connection.java:1675)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: org.apache.geode.SerializationException: Could not create an 
> instance of  
> org.apache.geode.internal.cache.partitioned.RegionAdvisor$PartitionProfile .
> at 
> org.apache.geode.internal.InternalDataSerializer.invokeFromData(InternalDataSerializer.java:2381)
> at 
> org.apache.geode.internal.DSFIDFactory.create(DSFIDFactory.java:981)
> at 
> org.apache.geode.internal.InternalDataSerializer.basicReadObject(InternalDataSerializer.java:2691)
> at 
> org.apache.geode.DataSerializer.readObject(DataSerializer.java:2961)
> at 
> org.apache.geode.internal.cache.CreateRegionProcessor$CreateRegionReplyMessage.fromData(CreateRegionProcessor.java:798)
> at 
> org.apache.geode.internal.InternalDataSerializer.invokeFromData(InternalDataSerializer.java:2370)
> ... 8 more
> Caused by: org.apache.geode.SerializationException: Could not create an 
> instance of  org.apache.geode.internal.cache.FilterProfile .
> at 
> 

[jira] [Commented] (GEODE-3185) CI failure (windows): org.apache.geode.internal.cache.BackupJUnitTest, 3 tests failing with java.lang.AssertionError: Null entry

[Darrel Schneider (JIRA)]

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

Darrel Schneider commented on GEODE-3185:
-

testCompactionDuringBackup also calls restoreBackup so it might have the same 
problem. Fixing the restore script to not have a hardcoded path to robocopy 
might fix all three failures.


> CI failure (windows): org.apache.geode.internal.cache.BackupJUnitTest, 3 
> tests failing with java.lang.AssertionError: Null entry
> 
>
> Key: GEODE-3185
> URL: https://issues.apache.org/jira/browse/GEODE-3185
> Project: Geode
>  Issue Type: Bug
>  Components: persistence
>Reporter: Lynn Gallinat
>
> {noformat}
> org.apache.geode.internal.cache.BackupJUnitTest > testBackupAndRecover FAILED
> java.lang.AssertionError: Null entry 512
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at 
> org.apache.geode.internal.cache.BackupJUnitTest.validateEntriesExist(BackupJUnitTest.java:354)
> at 
> org.apache.geode.internal.cache.BackupJUnitTest.backupAndRecover(BackupJUnitTest.java:229)
> at 
> org.apache.geode.internal.cache.BackupJUnitTest.testBackupAndRecover(BackupJUnitTest.java:126)
> org.apache.geode.internal.cache.BackupJUnitTest > testCompactionDuringBackup 
> FAILED
> java.lang.AssertionError: Null entry 0
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at 
> org.apache.geode.internal.cache.BackupJUnitTest.validateEntriesExist(BackupJUnitTest.java:354)
> at 
> org.apache.geode.internal.cache.BackupJUnitTest.testCompactionDuringBackup(BackupJUnitTest.java:309)
> org.apache.geode.internal.cache.BackupJUnitTest > 
> testBackupAndRecoverOldConfig FAILED
> java.lang.AssertionError: Null entry 512
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at 
> org.apache.geode.internal.cache.BackupJUnitTest.validateEntriesExist(BackupJUnitTest.java:354)
> at 
> org.apache.geode.internal.cache.BackupJUnitTest.backupAndRecover(BackupJUnitTest.java:229)
> at 
> org.apache.geode.internal.cache.BackupJUnitTest.testBackupAndRecoverOldConfig(BackupJUnitTest.java:136)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3187) CI failure (windows): org.apache.geode.internal.cache.persistence.BackupInspectorJUnitTest.testIncrementalBackupScript

[Darrel Schneider (JIRA)]

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

Darrel Schneider commented on GEODE-3187:
-

This failure revealed a couple of problems with the Windows specific backup 
code.
1. The BackupInspectionJUnitTest hard codes the contents of the restore scripts 
in a couple of java String constants. These String have diverged and no longer 
contain restore scripts that geode backup command will generate. The ones that 
are wrong are:
  
org.apache.geode.internal.cache.persistence.BackupInspectorJUnitTest.WINDOWS_INCREMENTAL_BACKUP_SCRIPT
  
org.apache.geode.internal.cache.persistence.BackupInspectorJUnitTest.WINDOWS_FULL_BACKUP_SCRIPT
Both of them contain "xcopy" and "copy" but the backup code now uses "robocopy" 
instead.

2. The method: 
org.apache.geode.internal.cache.persistence.WindowsBackupInspector.parseOplogLines(BufferedReader)
ask this: line.startsWith("robocopy")
But the code that generates these lines add this to the start of a line: 
"C:\\Windows\\System32\\Robocopy.exe". So it is never going to find "robocopy" 
and this will cause the inspector to never detect an incremental backup.
I think instead of looking for lines that start with "robocopy" it should just 
skip lines that start with "IF" and break if it contains EXIT_MARKER (it 
already does both of these). For any other line it should extract the oplog 
file name. This is basically what it does for linux.
3. It seems wrong for the backup command to generate 
"C:\\Windows\\System32\\Robocopy.exe". I could be wrong but I doubt that 
robocopy will always be in this location. It seems like we should all a search 
to be done for it in which case the generate code would just start the command 
line with "robocopy".


> CI failure (windows): 
> org.apache.geode.internal.cache.persistence.BackupInspectorJUnitTest.testIncrementalBackupScript
> --
>
> Key: GEODE-3187
> URL: https://issues.apache.org/jira/browse/GEODE-3187
> Project: Geode
>  Issue Type: Bug
>  Components: persistence
>Reporter: Lynn Gallinat
>
> {noformat}
> org.apache.geode.internal.cache.persistence.BackupInspectorJUnitTest > 
> testIncrementalBackupScript FAILED
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertTrue(Assert.java:52)
> at 
> org.apache.geode.internal.cache.persistence.BackupInspectorJUnitTest.testIncrementalBackupScript(BackupInspectorJUnitTest.java:198)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-2226) SessionReplicationIntegrationJUnitTest is broken on Windows

[Shelley Lynn Hughes-Godfrey (JIRA)]

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

Shelley Lynn Hughes-Godfrey commented on GEODE-2226:


The toolsmiths have added a new concourse job for windows testing ... and these 
are still failing.
Updated the component from "tests" to "http session".

org.apache.geode.modules.session.internal.filter.SessionReplicationIntegrationJUnitTest
 > testNativeSessionRemainsUnchanged FAILED
{noformat}
java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
at java.util.ArrayList.rangeCheck(ArrayList.java:653)
at java.util.ArrayList.get(ArrayList.java:429)
at 
org.apache.geode.modules.session.internal.filter.SessionReplicationIntegrationJUnitTest.testNativeSessionRemainsUnchanged(SessionReplicationIntegrationJUnitTest.java:1182)
{noformat}

org.apache.geode.modules.session.internal.filter.SessionReplicationIntegrationJUnitTest
 > testSessionRemains1 FAILED
{noformat}
org.junit.ComparisonFailure: Session should be new expected:<[new]> but 
was:<[

Error


The resource did not process correctly

org.apache.geode.cache.CacheClosedException: The cache is closed.
at 
org.apache.geode.internal.cache.GemFireCacheImpl$Stopper.generateCancelledException(GemFireCacheImpl.java:1519)
at 
org.apache.geode.CancelCriterion.checkCancelInProgress(CancelCriterion.java:83)
at 
org.apache.geode.internal.cache.LocalRegion.checkRegionDestroyed(LocalRegion.java:7423)
at 
org.apache.geode.internal.cache.LocalRegion.checkReadiness(LocalRegion.java:2728)
at 
org.apache.geode.internal.cache.LocalRegion.newUpdateEntryEvent(LocalRegion.java:1617)
at 
org.apache.geode.internal.cache.LocalRegion.put(LocalRegion.java:1577)
at 
org.apache.geode.internal.cache.AbstractRegion.put(AbstractRegion.java:325)
at 
org.apache.geode.modules.session.internal.filter.GemfireSessionManager.wrapSession(GemfireSessionManager.java:241)
at 
org.apache.geode.modules.session.filter.SessionCachingFilter$RequestWrapper.getSession(SessionCachingFilter.java:191)
at 
org.apache.geode.modules.session.filter.SessionCachingFilter$RequestWrapper.getSession(SessionCachingFilter.java:153)
at 
org.apache.geode.modules.session.internal.filter.SessionReplicationIntegrationJUnitTest$5.call(SessionReplicationIntegrationJUnitTest.java:250)
at 
org.apache.geode.modules.session.internal.filter.BasicServlet.doGet(BasicServlet.java:39)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at 
org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:845)
at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1689)
at 
org.apache.geode.modules.session.filter.SessionCachingFilter.doFilter(SessionCachingFilter.java:423)
at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1676)
at 
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:581)
at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
at 
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)
at 
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:511)
at 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
at 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)
at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
at org.eclipse.jetty.server.Server.handle(Server.java:524)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:319)
at 
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:253)
at 
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)
at 
org.eclipse.jetty.io.ByteArrayEndPoint$1.run(ByteArrayEndPoint.java:55)
at 
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:671)
at 
org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:589)
at java.lang.Thread.run(Thread.java:748)

]>
at org.junit.Assert.assertEquals(Assert.java:115)
at 

[jira] [Updated] (GEODE-2226) SessionReplicationIntegrationJUnitTest is broken on Windows

[Shelley Lynn Hughes-Godfrey (JIRA)]

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

Shelley Lynn Hughes-Godfrey updated GEODE-2226:
---
Component/s: (was: tests)
 http session

> SessionReplicationIntegrationJUnitTest is broken on Windows
> ---
>
> Key: GEODE-2226
> URL: https://issues.apache.org/jira/browse/GEODE-2226
> Project: Geode
>  Issue Type: Bug
>  Components: http session
>Affects Versions: 1.0.0-incubating
> Environment: Windows
>Reporter: Kirk Lund
>  Labels: IntegrationTest, Windows
>
> testAttributesUpdatedInRegion:
> {noformat}
> org.apache.geode.cache.CacheClosedException: The cache is closed.
>   at 
> org.apache.geode.internal.cache.GemFireCacheImpl$Stopper.generateCancelledException(GemFireCacheImpl.java:1576)
>   at 
> org.apache.geode.CancelCriterion.checkCancelInProgress(CancelCriterion.java:87)
>   at 
> org.apache.geode.internal.cache.GemFireCacheImpl.getRegion(GemFireCacheImpl.java:3496)
>   at 
> org.apache.geode.internal.cache.GemFireCacheImpl.getRegion(GemFireCacheImpl.java:3379)
>   at 
> org.apache.geode.modules.session.internal.filter.SessionReplicationIntegrationJUnitTest.getRegion(SessionReplicationIntegrationJUnitTest.java:1575)
>   at 
> org.apache.geode.modules.session.internal.filter.SessionReplicationIntegrationJUnitTest.testAttributesUpdatedInRegion(SessionReplicationIntegrationJUnitTest.java:329)
> 
> {noformat}
> testFailover1:
> {noformat}
> org.apache.geode.cache.CacheClosedException: The cache is closed.
>   at 
> org.apache.geode.internal.cache.GemFireCacheImpl$Stopper.generateCancelledException(GemFireCacheImpl.java:1576)
>   at 
> org.apache.geode.CancelCriterion.checkCancelInProgress(CancelCriterion.java:87)
>   at 
> org.apache.geode.internal.cache.GemFireCacheImpl.getRegion(GemFireCacheImpl.java:3496)
>   at 
> org.apache.geode.internal.cache.GemFireCacheImpl.getRegion(GemFireCacheImpl.java:3379)
>   at 
> org.apache.geode.modules.session.internal.filter.SessionReplicationIntegrationJUnitTest.getRegion(SessionReplicationIntegrationJUnitTest.java:1575)
>   at 
> org.apache.geode.modules.session.internal.filter.SessionReplicationIntegrationJUnitTest.testFailover1(SessionReplicationIntegrationJUnitTest.java:1383)
> 
> {noformat}
> testGetCreationTime:
> {noformat}
> java.lang.NumberFormatException: For input string: "
> 
> Error
> 
> 
> The resource did not process correctly
> 
> org.apache.geode.cache.CacheClosedException: The cache is closed.
>   at 
> org.apache.geode.internal.cache.GemFireCacheImpl$Stopper.generateCancelledException(GemFireCacheImpl.java:1576)
>   at 
> org.apache.geode.CancelCriterion.checkCancelInProgress(CancelCriterion.java:87)
>   at 
> org.apache.geode.internal.cache.LocalRegion.checkRegionDestroyed(LocalRegion.java:7631)
>   at 
> org.apache.geode.internal.cache.LocalRegion.checkReadiness(LocalRegion.java:2784)
>   at 
> org.apache.geode.internal.cache.LocalRegion.newUpdateEntryEvent(LocalRegion.java:1629)
>   at 
> org.apache.geode.internal.cache.LocalRegion.put(LocalRegion.java:1588)
>   at 
> org.apache.geode.internal.cache.AbstractRegion.put(AbstractRegion.java:277)
>   at 
> org.apache.geode.modules.session.internal.filter.GemfireSessionManager.wrapSession(GemfireSessionManager.java:243)
>   at 
> org.apache.geode.modules.session.filter.SessionCachingFilter$RequestWrapper.getSession(SessionCachingFilter.java:188)
>   at 
> org.apache.geode.modules.session.filter.SessionCachingFilter$RequestWrapper.getSession(SessionCachingFilter.java:138)
>   at 
> org.apache.geode.modules.session.internal.filter.SessionReplicationIntegrationJUnitTest$27.call(SessionReplicationIntegrationJUnitTest.java:1076)
>   at 
> org.apache.geode.modules.session.internal.filter.BasicServlet.doGet(BasicServlet.java:39)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
>   at 
> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:821)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1685)
>   at 
> org.apache.geode.modules.session.filter.SessionCachingFilter.doFilter(SessionCachingFilter.java:420)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1668)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:581)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
>   at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
>   at 
> 

[jira] [Assigned] (GEODE-3230) Delete unused commands in CliStrings and refactor redundant commands

[Emily Yeh (JIRA)]

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

Emily Yeh reassigned GEODE-3230:


Assignee: Emily Yeh

> Delete unused commands in CliStrings and refactor redundant commands
> 
>
> Key: GEODE-3230
> URL: https://issues.apache.org/jira/browse/GEODE-3230
> Project: Geode
>  Issue Type: Improvement
>  Components: gfsh
>Reporter: Emily Yeh
>Assignee: Emily Yeh
>
> There are a lot of commands in {{CliStrings}} that aren't used. For example, 
> {{start manager}} has a whole set of associated commands - 
> {{START_MANAGER__MEMBERNAME}}, {{START_MANAGER__DIR}}, 
> {{START_MANAGER__CLASSPATH}}, etc.) that don't seem to be used anywhere. 
> These commands should be deleted to clean up the code.
> There are also many commands that are redundant. For example, there are many 
> usages of {{"port"}}, {{"bind-address"}}, etc. These commands should be 
> refactored so that they are defined once, and all references to commands like 
> {{CREATE_GATEWAYRECEIVER__BINDADDRESS}} instead refer to a single unified 
> command like {{BIND_ADDRESS}}.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3112) CI failure: ClientFunctionTimeoutRegressionTest.testExecuteFunctionReadsDefaultTimeout

[ASF GitHub Bot (JIRA)]

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

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

Github user DivineEnder commented on the issue:

https://github.com/apache/geode/pull/639
  
@ladyVader @nabarunnag @boglesby @jhuynh1 @upthewaterspout @gesterzhou 


> CI failure: 
> ClientFunctionTimeoutRegressionTest.testExecuteFunctionReadsDefaultTimeout
> --
>
> Key: GEODE-3112
> URL: https://issues.apache.org/jira/browse/GEODE-3112
> Project: Geode
>  Issue Type: Bug
>  Components: functions
>Affects Versions: 1.2.0, 1.3.0
>Reporter: Shelley Lynn Hughes-Godfrey
>Assignee: David Anuta
>
> {noformat}
> org.apache.geode.internal.cache.execute.ClientFunctionTimeoutRegressionTest > 
> testExecuteFunctionReadsDefaultTimeout(false,6000,server) [3] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.internal.cache.execute.ClientFunctionTimeoutRegressionTest$$Lambda$21/1996321698.run
>  in VM 1 running on Host 11375a95c724 with 4 VMs
> at org.apache.geode.test.dunit.VM.invoke(VM.java:377)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:347)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:292)
> at 
> org.apache.geode.internal.cache.execute.ClientFunctionTimeoutRegressionTest.testExecuteFunctionReadsDefaultTimeout(ClientFunctionTimeoutRegressionTest.java:109)
> Caused by:
> org.junit.ComparisonFailure: [Server did not read 
> client_function_timeout from client.] expected:<[tru]e> but was:<[fals]e>
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native 
> Method)
> at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at 
> org.apache.geode.internal.cache.execute.ClientFunctionTimeoutRegressionTest.executeFunction(ClientFunctionTimeoutRegressionTest.java:179)
> at 
> org.apache.geode.internal.cache.execute.ClientFunctionTimeoutRegressionTest.lambda$testExecuteFunctionReadsDefaultTimeout$a0075c0$1(ClientFunctionTimeoutRegressionTest.java:109)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3112) CI failure: ClientFunctionTimeoutRegressionTest.testExecuteFunctionReadsDefaultTimeout

[ASF GitHub Bot (JIRA)]

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

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

GitHub user DivineEnder opened a pull request:

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

GEODE-3112: Fixing improper ordering of client timeout setting

Thank you for submitting a contribution to Apache Geode.

In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:

### For all changes:
- [ ] Is there a JIRA ticket associated with this PR? Is it referenced in 
the commit message?

- [ ] Has your PR been rebased against the latest commit within the target 
branch (typically `develop`)?

- [ ] Is your initial contribution a single, squashed commit?

- [ ] Does `gradlew build` run cleanly?

- [ ] Have you written or updated unit tests to verify your changes?

- [ ] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)?

### Note:
Please ensure that once the PR is submitted, you check travis-ci for build 
issues and
submit an update to your PR as soon as possible. If you need help, please 
send an
email to d...@geode.apache.org.


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

$ git pull https://github.com/DivineEnder/geode feature/GEODE-3112

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

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


commit 4cf98a4605c17f8c08bc878df2db99fb1d194b6e
Author: David Anuta 
Date:   2017-07-17T22:25:35Z

GEODE-3112: Fixing improper ordering of client timeout setting




> CI failure: 
> ClientFunctionTimeoutRegressionTest.testExecuteFunctionReadsDefaultTimeout
> --
>
> Key: GEODE-3112
> URL: https://issues.apache.org/jira/browse/GEODE-3112
> Project: Geode
>  Issue Type: Bug
>  Components: functions
>Affects Versions: 1.2.0, 1.3.0
>Reporter: Shelley Lynn Hughes-Godfrey
>Assignee: David Anuta
>
> {noformat}
> org.apache.geode.internal.cache.execute.ClientFunctionTimeoutRegressionTest > 
> testExecuteFunctionReadsDefaultTimeout(false,6000,server) [3] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.internal.cache.execute.ClientFunctionTimeoutRegressionTest$$Lambda$21/1996321698.run
>  in VM 1 running on Host 11375a95c724 with 4 VMs
> at org.apache.geode.test.dunit.VM.invoke(VM.java:377)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:347)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:292)
> at 
> org.apache.geode.internal.cache.execute.ClientFunctionTimeoutRegressionTest.testExecuteFunctionReadsDefaultTimeout(ClientFunctionTimeoutRegressionTest.java:109)
> Caused by:
> org.junit.ComparisonFailure: [Server did not read 
> client_function_timeout from client.] expected:<[tru]e> but was:<[fals]e>
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native 
> Method)
> at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at 
> org.apache.geode.internal.cache.execute.ClientFunctionTimeoutRegressionTest.executeFunction(ClientFunctionTimeoutRegressionTest.java:179)
> at 
> org.apache.geode.internal.cache.execute.ClientFunctionTimeoutRegressionTest.lambda$testExecuteFunctionReadsDefaultTimeout$a0075c0$1(ClientFunctionTimeoutRegressionTest.java:109)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3180) CI failure: org.apache.geode.internal.cache.partitioned.PersistentColocatedPartitionedRegionDUnitTest.testFullTreeOfColocatedChildPRsWithMissingRegions fails with org.m

[Nick Reich (JIRA)]

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

Nick Reich commented on GEODE-3180:
---

It looks like this is an intermittent timing issue within the test (looking at 
the git history, it has been "fixed" in GEODE-2095 before to try and deal with 
its flaky nature). Here is the problem region of code:
{code}
 // acknowledge interactions with the mock that have occurred
 verify(mockAppender, atLeastOnce()).getName();
 verify(mockAppender, atLeastOnce()).isStarted();
 try {
// Another delay before exiting the thread to make sure that missing region 
logging
// doesn't continue after all regions are created (delay > logInterval)
Thread.sleep(logInterval * 2);
verifyNoMoreInteractions(mockAppender);
  } finally {
logger.removeAppender(mockAppender);
  }
{code}

There still appears to be issues with this test and validating occurrences of 
logging. Do we have a better pattern for doing this? Do we want to be 
validating the occurrence of logging at all (instead of the actual behavior 
that has occurred)?

> CI failure: 
> org.apache.geode.internal.cache.partitioned.PersistentColocatedPartitionedRegionDUnitTest.testFullTreeOfColocatedChildPRsWithMissingRegions
>  fails with org.mockito.exceptions.verification.NoInteractionsWanted
> ---
>
> Key: GEODE-3180
> URL: https://issues.apache.org/jira/browse/GEODE-3180
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: Lynn Gallinat
>
> {noformat}
> org.apache.geode.internal.cache.partitioned.PersistentColocatedPartitionedRegionDUnitTest
>  > testFullTreeOfColocatedChildPRsWithMissingRegions FAILED
> java.lang.AssertionError: An exception occurred during asynchronous 
> invocation.
> at 
> org.apache.geode.test.dunit.AsyncInvocation.checkException(AsyncInvocation.java:148)
> at 
> org.apache.geode.test.dunit.AsyncInvocation.get(AsyncInvocation.java:422)
> at 
> org.apache.geode.internal.cache.partitioned.PersistentColocatedPartitionedRegionDUnitTest.testFullTreeOfColocatedChildPRsWithMissingRegions(PersistentColocatedPartitionedRegionDUnitTest.java:1298)
> Caused by:
> org.mockito.exceptions.verification.NoInteractionsWanted: 
> No interactions wanted here:
> -> at 
> org.apache.geode.internal.cache.partitioned.PersistentColocatedPartitionedRegionDUnitTest$14.call(PersistentColocatedPartitionedRegionDUnitTest.java:1232)
> But found this interaction on mock 'appender':
> -> at 
> org.apache.logging.log4j.core.config.AppenderControl.tryCallAppender(AppenderControl.java:156)
> ***
> For your reference, here is the list of all invocations ([?] - means 
> unverified).
> 1. -> at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.addLoggerAppender(AbstractConfiguration.java:694)
> 2. -> at 
> org.apache.logging.log4j.core.config.AppenderControl.(AppenderControl.java:51)
> 3. -> at 
> org.apache.logging.log4j.core.config.AppenderControl.ensureAppenderStarted(AppenderControl.java:134)
> 4. -> at 
> org.apache.logging.log4j.core.config.AppenderControl.tryCallAppender(AppenderControl.java:156)
> 5. -> at 
> org.apache.logging.log4j.core.config.AppenderControl.ensureAppenderStarted(AppenderControl.java:134)
> 6. [?]-> at 
> org.apache.logging.log4j.core.config.AppenderControl.tryCallAppender(AppenderControl.java:156){noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (GEODE-3230) Delete unused commands in CliStrings and refactor redundant commands

[Emily Yeh (JIRA)]

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

Emily Yeh updated GEODE-3230:
-
Summary: Delete unused commands in CliStrings and refactor redundant 
commands  (was: Delete unused commands in CliStrings)

> Delete unused commands in CliStrings and refactor redundant commands
> 
>
> Key: GEODE-3230
> URL: https://issues.apache.org/jira/browse/GEODE-3230
> Project: Geode
>  Issue Type: Improvement
>  Components: gfsh
>Reporter: Emily Yeh
>
> There are a lot of commands in {{CliStrings}} that aren't used. For example, 
> {{start manager}} has a whole set of associated commands - 
> {{START_MANAGER__MEMBERNAME}}, {{START_MANAGER__DIR}}, 
> {{START_MANAGER__CLASSPATH}}, etc.) that don't seem to be used anywhere. 
> These commands should be deleted to clean up the code.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (GEODE-3230) Delete unused commands in CliStrings

[Emily Yeh (JIRA)]

Emily Yeh created GEODE-3230:


 Summary: Delete unused commands in CliStrings
 Key: GEODE-3230
 URL: https://issues.apache.org/jira/browse/GEODE-3230
 Project: Geode
  Issue Type: Improvement
  Components: gfsh
Reporter: Emily Yeh


There are a lot of commands in {{CliStrings}} that aren't used. For example, 
{{start manager}} has a whole set of associated commands - 
{{START_MANAGER__MEMBERNAME}}, {{START_MANAGER__DIR}}, 
{{START_MANAGER__CLASSPATH}}, etc.) that don't seem to be used anywhere. These 
commands should be deleted to clean up the code.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3199) geode-examples on the release branch prompts for a gpg password

[ASF GitHub Bot (JIRA)]

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

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

Github user asfgit closed the pull request at:

https://github.com/apache/geode-examples/pull/9


> geode-examples on the release branch prompts for a gpg password
> ---
>
> Key: GEODE-3199
> URL: https://issues.apache.org/jira/browse/GEODE-3199
> Project: Geode
>  Issue Type: Bug
>  Components: build
>Reporter: Dan Smith
>
> When building geode-examples using ./gradlew build from the release/1.2.0 
> branch, I get prompted to enter my gpg password. Since our instructions on 
> running the examples tell the user to run gradlew build, they will hit this 
> prompt when building the released examples.
> Travis is also showing this failure:
> https://travis-ci.org/apache/geode-examples/builds/244002605
> {noformat}
> You must configure your signing.keyId and signing.secretKeyRingFile
> in ~/.gradle/gradle.properties in order to sign jars
> See https://cwiki.apache.org/confluence/display/GEODE/Release+Steps
> FAILURE: Build failed with an exception.
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3202) Add an example to demonstrate Lucene indexing and searching

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-3202:


Commit 500cc51a6b899a380603f2ab822b8a6bada97e41 in geode-examples's branch 
refs/heads/develop from [~dhardman]
[ https://git-wip-us.apache.org/repos/asf?p=geode-examples.git;h=500cc51 ]

GEODE-3202 Adding new lucene example.
This closes #10


> Add an example to demonstrate Lucene indexing and searching
> ---
>
> Key: GEODE-3202
> URL: https://issues.apache.org/jira/browse/GEODE-3202
> Project: Geode
>  Issue Type: New Feature
>  Components: lucene
>Reporter: Diane Hardman
>Assignee: Diane Hardman
>
> Create a simple example to demonstrate new Lucene feature.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3168) Fix CLI projects and tests.

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-3168:


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

GEODE-3168: Added Windows only conditional for disabled optimize


> Fix CLI projects and tests.
> ---
>
> Key: GEODE-3168
> URL: https://issues.apache.org/jira/browse/GEODE-3168
> Project: Geode
>  Issue Type: Task
>  Components: native client
>Reporter: Jacob S. Barrett
>Assignee: Jacob S. Barrett
>
> CLI projects and tests have path issues that can cause compile issues.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (GEODE-3031) Extract startLocator and startServer from LauncherLifecycleCommands

[Emily Yeh (JIRA)]

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

Emily Yeh reassigned GEODE-3031:


Assignee: Emily Yeh

> Extract startLocator and startServer from LauncherLifecycleCommands
> ---
>
> Key: GEODE-3031
> URL: https://issues.apache.org/jira/browse/GEODE-3031
> Project: Geode
>  Issue Type: Improvement
>  Components: gfsh
>Reporter: Jared Stewart
>Assignee: Emily Yeh
>
> LauncherLifecycleCommands is a huge class that contains both startServer and 
> startLocator.  We ought to extract those command methods into their own 
> classes, and figure out a sensible home for the shared, common methods from 
> LauncherLifecycleCommands used by both commands.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3141) New flow: GetRegion

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/geode/pull/630#discussion_r127820947
  
--- Diff: geode-protobuf/src/main/proto/basicTypes.proto ---
@@ -52,7 +52,12 @@ message CallbackArguments {
 
 message Region {
--- End diff --

Why not inline the contents of this in `GetRegionResponse`?


> New flow: GetRegion
> ---
>
> Key: GEODE-3141
> URL: https://issues.apache.org/jira/browse/GEODE-3141
> Project: Geode
>  Issue Type: Sub-task
>  Components: client/server
>Reporter: Brian Baynes
>Assignee: Udo Kohlmeyer
>
> Users of the new client/server protocol need to be able to verify a region 
> exists in the cache. Implement GetRegion message/handler, returning boolean 
> success(/failure) based on the existence of a Region when passed a Region 
> name.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3166) AuthInitize interface non-deprecated api is never called

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-3166:


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

GEODE-3166: use the 3 param getCredential interface.


> AuthInitize interface non-deprecated api is never called
> 
>
> Key: GEODE-3166
> URL: https://issues.apache.org/jira/browse/GEODE-3166
> Project: Geode
>  Issue Type: Bug
>Reporter: Jinmei Liao
>
> this interface default Properties getCredentials(Properties securityProps)  
> is never used by the product.
> The older interface is used because we still need to support the old 
> authenticator, therefore we can't update the product to use the new interface 
> just yet. Need to remove the deprecated annotation and this interface method.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3048) Tests that require the Gradle test runner should fail descriptively when run through Intellij

[ASF GitHub Bot (JIRA)]

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

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

Github user YehEmily closed the pull request at:

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


> Tests that require the Gradle test runner should fail descriptively when run 
> through Intellij
> -
>
> Key: GEODE-3048
> URL: https://issues.apache.org/jira/browse/GEODE-3048
> Project: Geode
>  Issue Type: Bug
>  Components: management, tests
>Reporter: Jared Stewart
>Assignee: Jared Stewart
>
> We have some tests the only pass when run through gradle (as opposed to 
> running via the Intellij test runner).  If one of these tests fails in CI, it 
> is easy to being debugging them in the IDE without realizing that they will 
> *never* pass when not run via gradle.  Until we fix the underlying issues 
> that require running through gradle, it would be nice for such tests to 
> detect when they are running outside of gradle, and to notify the user that 
> they should be expected to fail.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-2203) gfsh status locator/server - Give more descriptive output on empty parameter

[ASF GitHub Bot (JIRA)]

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

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

Github user YehEmily closed the pull request at:

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


> gfsh status locator/server - Give more descriptive output on empty parameter
> 
>
> Key: GEODE-2203
> URL: https://issues.apache.org/jira/browse/GEODE-2203
> Project: Geode
>  Issue Type: Improvement
>  Components: gfsh
>Reporter: Alyssa Kim
>Assignee: Emily Yeh
>Priority: Minor
>  Labels: StatusLocatorCommand, StatusServerCommand, gfsh, status
>
> Currently, executing some status commands in gfsh without valid parameters 
> gives a vague explanation/output that might be misleading. Although we have 
> help  for usage description, displaying 'null' as an output 
> might not be the best idea.
> Current Result
> {code}
> gfsh>status locator
> null
> {code}
> {code}
> gfsh>status server
> Server in 
> C:\Users\XXX\git\incubator-geode\geode-assembly\build\install\apache-geode\bin
>  on null is currently not responding.
> {code}
> Improvement
> {code}
> gfsh>status locator
> SYNTAX
> status locator [--name=value] [--host=value] [--port=value] [--pid=value]
> Use help status locator to display detailed usage information
> {code}
> {code}
> gfsh>status server
> SYNTAX
> status server [--name=value] [--pid=value] [--dir=value]
> Use help status server to display detailed usage information
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3141) New flow: GetRegion

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-3141:


Commit 9e9950f37363e13971372b70d46ae7f5ccbcc9ce in geode's branch 
refs/heads/feature/GEODE-3141 from [~ukohlmeyer]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=9e9950f ]

GEODE-3141: Remove misleading comment


> New flow: GetRegion
> ---
>
> Key: GEODE-3141
> URL: https://issues.apache.org/jira/browse/GEODE-3141
> Project: Geode
>  Issue Type: Sub-task
>  Components: client/server
>Reporter: Brian Baynes
>Assignee: Udo Kohlmeyer
>
> Users of the new client/server protocol need to be able to verify a region 
> exists in the cache. Implement GetRegion message/handler, returning boolean 
> success(/failure) based on the existence of a Region when passed a Region 
> name.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (GEODE-3229) The PutAllOperationHandler is currently stateful. Needs to be stateless

[Udo Kohlmeyer (JIRA)]

Udo Kohlmeyer created GEODE-3229:


 Summary: The PutAllOperationHandler is currently stateful. Needs 
to be stateless
 Key: GEODE-3229
 URL: https://issues.apache.org/jira/browse/GEODE-3229
 Project: Geode
  Issue Type: Bug
  Components: client/server, serialization
Reporter: Udo Kohlmeyer


The current implementation for the Protobuf Operation Handler for PutAll is 
stateful.
This needs to be changed so that it becomes stateless.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (GEODE-3207) Swagger library updates: update user guide

[Dave Barnes (JIRA)]

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

Dave Barnes resolved GEODE-3207.

   Resolution: Fixed
Fix Version/s: (was: 1.1.0)
   1.3.0

SW issue resolved in v1.1.0. Docs updated for v1.3.0

> Swagger library updates: update user guide
> --
>
> Key: GEODE-3207
> URL: https://issues.apache.org/jira/browse/GEODE-3207
> Project: Geode
>  Issue Type: Sub-task
>  Components: docs
>Reporter: Dave Barnes
>Assignee: Dave Barnes
> Fix For: 1.3.0
>
>
> Doc impact (from a talk with Kevin Duling, 10/20/2016). See page 
> http://geode.docs.pivotal.io/docs/rest_apps/using_swagger.html, "Using the 
> Swagger UI to Browse REST APIs".
> Step 1 example showing gfsh command line to start Geode. Replace 
> "--J=-Dgemfire.start-dev-rest-api=true" with "--start-rest-api".
> Delete "--J=-Dgemfire.http-service-bind-address=localhost"
> Delete both "jmx-manager" options
> Step 2, replace "localhost" with a placeholder for "this machine's default IP 
> address".



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (GEODE-3228) Query Interface Specification Definition

[Udo Kohlmeyer (JIRA)]

Udo Kohlmeyer created GEODE-3228:


 Summary: Query Interface Specification Definition
 Key: GEODE-3228
 URL: https://issues.apache.org/jira/browse/GEODE-3228
 Project: Geode
  Issue Type: Sub-task
  Components: client/server, serialization
Reporter: Udo Kohlmeyer






--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (GEODE-3227) GetAvailableServers Specification Definition

[Udo Kohlmeyer (JIRA)]

Udo Kohlmeyer created GEODE-3227:


 Summary: GetAvailableServers Specification Definition
 Key: GEODE-3227
 URL: https://issues.apache.org/jira/browse/GEODE-3227
 Project: Geode
  Issue Type: Sub-task
  Components: client/server, serialization
Reporter: Udo Kohlmeyer






--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3207) Swagger library updates: update user guide

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-3207:


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

GEODE-3207 Swagger library updates: update user guide


> Swagger library updates: update user guide
> --
>
> Key: GEODE-3207
> URL: https://issues.apache.org/jira/browse/GEODE-3207
> Project: Geode
>  Issue Type: Sub-task
>  Components: docs
>Reporter: Dave Barnes
>Assignee: Dave Barnes
> Fix For: 1.1.0
>
>
> Doc impact (from a talk with Kevin Duling, 10/20/2016). See page 
> http://geode.docs.pivotal.io/docs/rest_apps/using_swagger.html, "Using the 
> Swagger UI to Browse REST APIs".
> Step 1 example showing gfsh command line to start Geode. Replace 
> "--J=-Dgemfire.start-dev-rest-api=true" with "--start-rest-api".
> Delete "--J=-Dgemfire.http-service-bind-address=localhost"
> Delete both "jmx-manager" options
> Step 2, replace "localhost" with a placeholder for "this machine's default IP 
> address".



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (GEODE-3226) GetAvailableRegionNames Specification Definition

[Udo Kohlmeyer (JIRA)]

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

Udo Kohlmeyer updated GEODE-3226:
-
Summary: GetAvailableRegionNames Specification Definition  (was: 
GetRegionNames Specification Definition)

> GetAvailableRegionNames Specification Definition
> 
>
> Key: GEODE-3226
> URL: https://issues.apache.org/jira/browse/GEODE-3226
> Project: Geode
>  Issue Type: Sub-task
>  Components: client/server, serialization
>Reporter: Udo Kohlmeyer
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-2189) Docs: Update Swagger UI links

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2189:


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

GEODE-2189 Docs: Update Swagger UI links
Added link to OpenAPI specification.


> Docs: Update Swagger UI links
> -
>
> Key: GEODE-2189
> URL: https://issues.apache.org/jira/browse/GEODE-2189
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Dave Barnes
>Assignee: Dave Barnes
>Priority: Minor
> Fix For: 1.3.0
>
>
> In the User Manual, at the bottom of the section Developing REST Applications 
> -> Using the Swagger UI, there are two links, one to "more info" and one to 
> the "Swagger specification". The first one no longer connects to anything, 
> the second connects to a target that may be incorrect.
> Need to review and update these links with their correct values. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (GEODE-3226) GetRegionNames Specification Definition

[Udo Kohlmeyer (JIRA)]

Udo Kohlmeyer created GEODE-3226:


 Summary: GetRegionNames Specification Definition
 Key: GEODE-3226
 URL: https://issues.apache.org/jira/browse/GEODE-3226
 Project: Geode
  Issue Type: Sub-task
  Components: client/server, serialization
Reporter: Udo Kohlmeyer






--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (GEODE-3225) GetRegion Specification Definitio

[Udo Kohlmeyer (JIRA)]

Udo Kohlmeyer created GEODE-3225:


 Summary: GetRegion Specification Definitio
 Key: GEODE-3225
 URL: https://issues.apache.org/jira/browse/GEODE-3225
 Project: Geode
  Issue Type: Sub-task
  Components: client/server, serialization
Reporter: Udo Kohlmeyer






--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (GEODE-3225) GetRegion Specification Definition

[Udo Kohlmeyer (JIRA)]

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

Udo Kohlmeyer updated GEODE-3225:
-
Summary: GetRegion Specification Definition  (was: GetRegion Specification 
Definitio)

> GetRegion Specification Definition
> --
>
> Key: GEODE-3225
> URL: https://issues.apache.org/jira/browse/GEODE-3225
> Project: Geode
>  Issue Type: Sub-task
>  Components: client/server, serialization
>Reporter: Udo Kohlmeyer
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (GEODE-2189) Docs: Update Swagger UI links

[Dave Barnes (JIRA)]

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

Dave Barnes resolved GEODE-2189.

   Resolution: Fixed
Fix Version/s: 1.3.0

Updated links as follows, verified that they work correctly.
For more information on Swagger, see the [Swagger website](http://swagger.io/) 
and the [OpenAPI specification](https://github.com/OAI/OpenAPI-Specification).

> Docs: Update Swagger UI links
> -
>
> Key: GEODE-2189
> URL: https://issues.apache.org/jira/browse/GEODE-2189
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Dave Barnes
>Assignee: Dave Barnes
>Priority: Minor
> Fix For: 1.3.0
>
>
> In the User Manual, at the bottom of the section Developing REST Applications 
> -> Using the Swagger UI, there are two links, one to "more info" and one to 
> the "Swagger specification". The first one no longer connects to anything, 
> the second connects to a target that may be incorrect.
> Need to review and update these links with their correct values. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (GEODE-3224) RemoveAll Specification Definition

[Udo Kohlmeyer (JIRA)]

Udo Kohlmeyer created GEODE-3224:


 Summary: RemoveAll Specification Definition
 Key: GEODE-3224
 URL: https://issues.apache.org/jira/browse/GEODE-3224
 Project: Geode
  Issue Type: Sub-task
  Components: client/server, serialization
Reporter: Udo Kohlmeyer






--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (GEODE-3223) Remove Specification Definition

[Udo Kohlmeyer (JIRA)]

Udo Kohlmeyer created GEODE-3223:


 Summary: Remove Specification Definition
 Key: GEODE-3223
 URL: https://issues.apache.org/jira/browse/GEODE-3223
 Project: Geode
  Issue Type: Sub-task
  Components: client/server, serialization
Reporter: Udo Kohlmeyer






--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (GEODE-3222) PutAll Specification Definiton

[Udo Kohlmeyer (JIRA)]

Udo Kohlmeyer created GEODE-3222:


 Summary: PutAll Specification Definiton
 Key: GEODE-3222
 URL: https://issues.apache.org/jira/browse/GEODE-3222
 Project: Geode
  Issue Type: Sub-task
  Components: client/server, serialization
Reporter: Udo Kohlmeyer






--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (GEODE-3220) Put Specification Definition

[Udo Kohlmeyer (JIRA)]

Udo Kohlmeyer created GEODE-3220:


 Summary: Put Specification Definition
 Key: GEODE-3220
 URL: https://issues.apache.org/jira/browse/GEODE-3220
 Project: Geode
  Issue Type: Sub-task
  Components: client/server, serialization
Reporter: Udo Kohlmeyer






--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (GEODE-3218) Client-Server protocol API Specification

[Udo Kohlmeyer (JIRA)]

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

Udo Kohlmeyer updated GEODE-3218:
-
Description: 
This is a parent task to track the specification of the client-server protocol 
API.
This specification will contain:
* Message definition (Request/Response)
* Use Cases and expected results

  was:This is a parent task to track the specification of the client-server 
protocol API


> Client-Server protocol API Specification
> 
>
> Key: GEODE-3218
> URL: https://issues.apache.org/jira/browse/GEODE-3218
> Project: Geode
>  Issue Type: Task
>  Components: client/server, serialization
>Reporter: Udo Kohlmeyer
>
> This is a parent task to track the specification of the client-server 
> protocol API.
> This specification will contain:
> * Message definition (Request/Response)
> * Use Cases and expected results



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (GEODE-3219) Get Specification Definition

[Udo Kohlmeyer (JIRA)]

Udo Kohlmeyer created GEODE-3219:


 Summary: Get Specification Definition
 Key: GEODE-3219
 URL: https://issues.apache.org/jira/browse/GEODE-3219
 Project: Geode
  Issue Type: Sub-task
  Components: client/server, serialization
Reporter: Udo Kohlmeyer






--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (GEODE-3218) Client-Server protocol API Specification

[Udo Kohlmeyer (JIRA)]

Udo Kohlmeyer created GEODE-3218:


 Summary: Client-Server protocol API Specification
 Key: GEODE-3218
 URL: https://issues.apache.org/jira/browse/GEODE-3218
 Project: Geode
  Issue Type: Task
  Components: client/server, serialization
Reporter: Udo Kohlmeyer


This is a parent task to track the specification of the client-server protocol 
API



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3213) Refactor Protobuf Serialization Implemenation

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-3213:


Commit 2033ba7b4198e9935fd0f4b40c708a359c4e4e65 in geode's branch 
refs/heads/feature/GEODE-3213 from [~ukohlmeyer]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=2033ba7 ]

GEODE-3213: Initial refactor for Protobuf protocol generic flow


> Refactor Protobuf Serialization Implemenation
> -
>
> Key: GEODE-3213
> URL: https://issues.apache.org/jira/browse/GEODE-3213
> Project: Geode
>  Issue Type: Improvement
>  Components: client/server, serialization
>Reporter: Udo Kohlmeyer
>
> In the Protobuf serialization implementation, there are some refactorings we 
> want to make:
> * OperationHandlers take OperationRequest and OperationResponse message, not 
> the parent Request/Response Object
> * A generic flow needs to be implemented that all OperationHandlers follow. 
> No bespoke flows for any OperationHandlers... way too much maintenance
> * Use Functional semantics to configure the functionality to extract 
> OperationRequest from Request (per OperationHandler)
> * Use Functional semantics to configure the functionality to populate 
> OperationResponse in the relevant Response
> * Have generic Error Handling framework to populate "known" errors and error 
> codes



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (GEODE-3214) Remove support for multistep Gfsh commands

[Jared Stewart (JIRA)]

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

Jared Stewart updated GEODE-3214:
-
Summary: Remove support for multistep Gfsh commands  (was: Remove Multistep 
Commands)

> Remove support for multistep Gfsh commands
> --
>
> Key: GEODE-3214
> URL: https://issues.apache.org/jira/browse/GEODE-3214
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Reporter: Jared Stewart
>
> The implementation of Multistep commands is needlessly complex and buggy.  
> After GEODE-3217, we should be able to remove the notion of multistep 
> commands entirely.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3153) Client receives duplicate events during rolling upgrade

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-3153:


Commit 2974dab327c5d21e55a21c17fe657597a20c6612 in geode's branch 
refs/heads/master from [~hitesh.khamesra]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=2974dab ]

GEODE-3153 applied spotless


> Client receives duplicate events during rolling upgrade
> ---
>
> Key: GEODE-3153
> URL: https://issues.apache.org/jira/browse/GEODE-3153
> Project: Geode
>  Issue Type: Bug
>  Components: client queues
>Reporter: Dan Smith
> Fix For: 1.2.0
>
>
> During a rolling upgrade from 1.1 to 1.2, we see 1.1 client receive duplicate 
> events.
> This is the scenario
> 1) 1.1 peer is doing puts
> 2) 1.1 client has registered interest, and is connected to a 1.1 server
> 3) 1.1 server is upgraded to a 1.2 server
> 4) The client may receive some of the events that are being put twice.
> Looking further, it appears that when a put goes through a 1.1 server to a 
> 1.1 client, the member id includes a 17 byte unique id as the last part of 
> the serialized data. When the put goes through a 1.2 server, those 17 bytes 
> become zeros.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3139) remove geode-core/src/main artifacts from classpath of backward-compatibility tests

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-3139:


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

Revert "Revert "GEODE-3139 remove current artifacts from classpath of 
backward-compatibility tests""

This reverts commit 9f55eb12551488ca77cfb2a11283cf8f33657938.


> remove geode-core/src/main artifacts from classpath of backward-compatibility 
> tests
> ---
>
> Key: GEODE-3139
> URL: https://issues.apache.org/jira/browse/GEODE-3139
> Project: Geode
>  Issue Type: Bug
>  Components: build
>Reporter: Bruce Schuchardt
>Assignee: Bruce Schuchardt
> Fix For: 1.2.0
>
>
> When a JVM is launched to run an old version of GEODE its classpath currently 
> includes the old version's jars but also includes the current version's 
> classes, resources and generated-resources directories.  This could cause the 
> JVM to function differently than expected if the test happens to reference 
> some new class or an API that doesn't exist in the old version.
> I removed these directories from the classpath and found that the tests all 
> break when the couldn't find InternalClientCache, a new interface that is now 
> referenced by the test framework.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3172) Clients miss events when servers are upgraded from 1.0 to 1.2 due to serialization issues with HAEventWrapper

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-3172:


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

GEODE-3172: Fix serialization errors copying queue between 1.0 and 1.2

Deserialize a HAEventWrapper using the version of the sender when
receiving a GII.

Serialize entries using the version of the remote member when sending
data as part of GII. This works for the client queues because client
queues always have deserialized values. If there is an internal region
that has serialized values in memory, those values would still be copied
on the wire directly without being translated to the old members
version.

Adding a test that demonstrates the serialization issues we were seeing
with this issue. The test starts a 1.0 server, puts some data in the
queue and starts a 1.2 server.

This closes #620


> Clients miss events when servers are upgraded from 1.0 to 1.2 due to 
> serialization issues with HAEventWrapper
> -
>
> Key: GEODE-3172
> URL: https://issues.apache.org/jira/browse/GEODE-3172
> Project: Geode
>  Issue Type: Bug
>  Components: client queues, membership
>Reporter: Dan Smith
>Assignee: Dan Smith
> Fix For: 1.2.0
>
>
> We're seeing another data loss issue when upgrading servers due to 
> GEODE-2137. The issue is that we store HAEventWrapper objects in a region for 
> server->client queues. These objects contain a member ID. Because the objects 
> are region values, they can be lazily deserialized using the version of the 
> current member, which may not match the version of the member they were 
> serialized with.
> What we are seeing is that when a client is creating a queue on a 9.1 server, 
> and it is copying the contents of the queue from a 9.0 server, we get are 
> getting serialization errors which prevent the queue from being created. When 
> the 9.0 server is killed as part of a rolling upgrade, this results in event 
> loss.
> {noformat}
> [severe 2017/07/06 15:09:52.195 PDT  6> tid=0xc0] Uncaught exception in thread Thread[Handshaker 
> 0.0.0.0/0.0.0.0:23779 Thread 6,5,Handshaker 0.0.0.0/0.0.0.0:23779]
> org.apache.geode.InternalGemFireError: unexpected typeCode: -126
>   at Remote Member '172.1.1.1(32406):32771' in 
> org.apache.geode.internal.InternalDataSerializer.decodePrimitiveClass(InternalDataSerializer.java:1880)
>   at Remote Member '172.1.1.1(32406):32771' in 
> org.apache.geode.DataSerializer.readClass(DataSerializer.java:264)
>   at Remote Member '172.1.1.1(32406):32771' in 
> org.apache.geode.internal.InternalDataSerializer.basicReadObject(InternalDataSerializer.java:2707)
>   at Remote Member '172.1.1.1(32406):32771' in 
> org.apache.geode.DataSerializer.readObject(DataSerializer.java:2961)
>   at Remote Member '172.1.1.1(32406):32771' in 
> org.apache.geode.internal.cache.tier.sockets.HAEventWrapper.fromData(HAEventWrapper.java:330)
>   at Remote Member '172.1.1.1(32406):32771' in 
> org.apache.geode.internal.InternalDataSerializer.invokeFromData(InternalDataSerializer.java:2370)
>   at Remote Member '172.1.1.1(32406):32771' in 
> org.apache.geode.internal.DSFIDFactory.create(DSFIDFactory.java:981)
>   at Remote Member '172.1.1.1(32406):32771' in 
> org.apache.geode.internal.InternalDataSerializer.basicReadObject(InternalDataSerializer.java:2691)
>   at Remote Member '172.1.1.1(32406):32771' in 
> org.apache.geode.DataSerializer.readObject(DataSerializer.java:2961)
>   at Remote Member '172.1.1.1(32406):32771' in 
> org.apache.geode.internal.util.BlobHelper.deserializeBlob(BlobHelper.java:99)
>   at Remote Member '172.1.1.1(32406):32771' in 
> org.apache.geode.internal.cache.EntryEventImpl.deserialize(EntryEventImpl.java:1911)
>   at Remote Member '172.1.1.1(32406):32771' in 
> org.apache.geode.internal.cache.EntryEventImpl.deserialize(EntryEventImpl.java:1904)
>   at Remote Member '172.1.1.1(32406):32771' in 
> org.apache.geode.internal.cache.VMCachedDeserializable.getDeserializedValue(VMCachedDeserializable.java:134)
>   at Remote Member '172.1.1.1(32406):32771' in 
> org.apache.geode.internal.cache.AbstractRegionMap.initialImagePut(AbstractRegionMap.java:771)
>   at Remote Member '172.1.1.1(32406):32771' in 
> org.apache.geode.internal.cache.InitialImageOperation.processChunk(InitialImageOperation.java:928)
>   at Remote Member '172.1.1.1(32406):32771' in 
> org.apache.geode.internal.cache.InitialImageOperation$ImageProcessor.process(InitialImageOperation.java:1249)

[jira] [Commented] (GEODE-3153) Client receives duplicate events during rolling upgrade

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-3153:


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

GEODE-3139 remove artifacts from classpath of backward-compatibility tests

reinstating this - passes precheckin

GEODE-3153 Client receives duplicate events during rolling upgrade

Another problem was found in backward-compatibility testing.  If a
1.0.0 client was receiving subscription events generated by a 1.0.0
peer "feeder" member and the events were routed through a 1.0.0 server
the client might see duplicate events when the server is stopped and
the client fails over to a 1.2.0 server holding its redundant
subscription queue.  This is especially possible if a large "ack"
period is established in the client.

The problem stems from the EventID deserialization/reserialization of
the memberID bytes when sending to a 1.0 client.  It was deserializing
using Version.CURRENT, which ignores the UUID bytes in the serialized ID.
Then it serialized the identifier using the client's version, which
includes the UUID bytes but which are zero due to the version used
in deserialization.


> Client receives duplicate events during rolling upgrade
> ---
>
> Key: GEODE-3153
> URL: https://issues.apache.org/jira/browse/GEODE-3153
> Project: Geode
>  Issue Type: Bug
>  Components: client queues
>Reporter: Dan Smith
> Fix For: 1.2.0
>
>
> During a rolling upgrade from 1.1 to 1.2, we see 1.1 client receive duplicate 
> events.
> This is the scenario
> 1) 1.1 peer is doing puts
> 2) 1.1 client has registered interest, and is connected to a 1.1 server
> 3) 1.1 server is upgraded to a 1.2 server
> 4) The client may receive some of the events that are being put twice.
> Looking further, it appears that when a put goes through a 1.1 server to a 
> 1.1 client, the member id includes a 17 byte unique id as the last part of 
> the serialized data. When the put goes through a 1.2 server, those 17 bytes 
> become zeros.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3139) remove geode-core/src/main artifacts from classpath of backward-compatibility tests

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-3139:


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

Revert "GEODE-3139 remove current artifacts from classpath of 
backward-compatibility tests"

This reverts commit 84bf7394aaa13cc2da4b20b33c1242348b69f7ea.

This revision may have caused CI failures.  I'm reverting it now
just in case.


> remove geode-core/src/main artifacts from classpath of backward-compatibility 
> tests
> ---
>
> Key: GEODE-3139
> URL: https://issues.apache.org/jira/browse/GEODE-3139
> Project: Geode
>  Issue Type: Bug
>  Components: build
>Reporter: Bruce Schuchardt
>Assignee: Bruce Schuchardt
> Fix For: 1.2.0
>
>
> When a JVM is launched to run an old version of GEODE its classpath currently 
> includes the old version's jars but also includes the current version's 
> classes, resources and generated-resources directories.  This could cause the 
> JVM to function differently than expected if the test happens to reference 
> some new class or an API that doesn't exist in the old version.
> I removed these directories from the classpath and found that the tests all 
> break when the couldn't find InternalClientCache, a new interface that is now 
> referenced by the test framework.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3153) Client receives duplicate events during rolling upgrade

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-3153:


Commit 60225b9b760d9dae25ce07b853ac3fd01468fd80 in geode's branch 
refs/heads/master from [~hitesh.khamesra]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=60225b9 ]

GEODE-3153 Client receives duplicate events during rolling upgrade

The previous fix worked fine for 1.0.0 and 1.1.0 clients but there are
old GemFire 8.2 clients still in use that the fix did not work for.
This patch changes the serialization to always send UUID bytes to pre
Version.GFE_90 (1.0.0-incubating) clients.

Added unit for it


> Client receives duplicate events during rolling upgrade
> ---
>
> Key: GEODE-3153
> URL: https://issues.apache.org/jira/browse/GEODE-3153
> Project: Geode
>  Issue Type: Bug
>  Components: client queues
>Reporter: Dan Smith
> Fix For: 1.2.0
>
>
> During a rolling upgrade from 1.1 to 1.2, we see 1.1 client receive duplicate 
> events.
> This is the scenario
> 1) 1.1 peer is doing puts
> 2) 1.1 client has registered interest, and is connected to a 1.1 server
> 3) 1.1 server is upgraded to a 1.2 server
> 4) The client may receive some of the events that are being put twice.
> Looking further, it appears that when a put goes through a 1.1 server to a 
> 1.1 client, the member id includes a 17 byte unique id as the last part of 
> the serialized data. When the put goes through a 1.2 server, those 17 bytes 
> become zeros.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3139) remove geode-core/src/main artifacts from classpath of backward-compatibility tests

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-3139:


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

GEODE-3139 remove artifacts from classpath of backward-compatibility tests

reinstating this - passes precheckin

GEODE-3153 Client receives duplicate events during rolling upgrade

Another problem was found in backward-compatibility testing.  If a
1.0.0 client was receiving subscription events generated by a 1.0.0
peer "feeder" member and the events were routed through a 1.0.0 server
the client might see duplicate events when the server is stopped and
the client fails over to a 1.2.0 server holding its redundant
subscription queue.  This is especially possible if a large "ack"
period is established in the client.

The problem stems from the EventID deserialization/reserialization of
the memberID bytes when sending to a 1.0 client.  It was deserializing
using Version.CURRENT, which ignores the UUID bytes in the serialized ID.
Then it serialized the identifier using the client's version, which
includes the UUID bytes but which are zero due to the version used
in deserialization.


> remove geode-core/src/main artifacts from classpath of backward-compatibility 
> tests
> ---
>
> Key: GEODE-3139
> URL: https://issues.apache.org/jira/browse/GEODE-3139
> Project: Geode
>  Issue Type: Bug
>  Components: build
>Reporter: Bruce Schuchardt
>Assignee: Bruce Schuchardt
> Fix For: 1.2.0
>
>
> When a JVM is launched to run an old version of GEODE its classpath currently 
> includes the old version's jars but also includes the current version's 
> classes, resources and generated-resources directories.  This could cause the 
> JVM to function differently than expected if the test happens to reference 
> some new class or an API that doesn't exist in the old version.
> I removed these directories from the classpath and found that the tests all 
> break when the couldn't find InternalClientCache, a new interface that is now 
> referenced by the test framework.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3139) remove geode-core/src/main artifacts from classpath of backward-compatibility tests

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-3139:


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

GEODE-3139: Fixing compilation errors

ProcessManager appears to have been screwed up in the merge from
develop. Changed the class so that it matches the contents on develop.


> remove geode-core/src/main artifacts from classpath of backward-compatibility 
> tests
> ---
>
> Key: GEODE-3139
> URL: https://issues.apache.org/jira/browse/GEODE-3139
> Project: Geode
>  Issue Type: Bug
>  Components: build
>Reporter: Bruce Schuchardt
>Assignee: Bruce Schuchardt
> Fix For: 1.2.0
>
>
> When a JVM is launched to run an old version of GEODE its classpath currently 
> includes the old version's jars but also includes the current version's 
> classes, resources and generated-resources directories.  This could cause the 
> JVM to function differently than expected if the test happens to reference 
> some new class or an API that doesn't exist in the old version.
> I removed these directories from the classpath and found that the tests all 
> break when the couldn't find InternalClientCache, a new interface that is now 
> referenced by the test framework.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3152) A client connecting to a server with one version creates an HARegion name different from the one created in another version

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-3152:


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

GEODE-3152: Changed to create a region name appropriate to the client version

(cherry picked from commit 55f7a1c9f1f152a6d2f8643d5e71fe3fa9986a51)


> A client connecting to a server with one version creates an HARegion name 
> different from the one created in another version
> ---
>
> Key: GEODE-3152
> URL: https://issues.apache.org/jira/browse/GEODE-3152
> Project: Geode
>  Issue Type: Bug
>  Components: client queues
>Reporter: Barry Oglesby
>Assignee: Barry Oglesby
> Fix For: 1.2.0
>
>
> What is happening is:
> 904 client -> 91 server results in an HARegion name containing the version 
> like:
> {noformat}
> Initializing region 
> _gfe_non_durable_client_with_id_192.168.2.4(client:98892:loner):57839:927197eb:client(version:GFE
>  9.0)_2_queue
> {noformat}
> 904 client -> 904 server or 91 client -> 91 server results in an HARegion 
> name without the version like:
> {noformat}
> Initializing region 
> _gfe_non_durable_client_with_id_192.168.2.4(client:98892:loner):57839:927197eb:client_2_queue
> {noformat}
> This causes secondary queue removal and GII to fail.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (GEODE-3217) Reimplement GFSH Query as a single-step command

[Jared Stewart (JIRA)]

Jared Stewart created GEODE-3217:


 Summary: Reimplement GFSH Query as a single-step command
 Key: GEODE-3217
 URL: https://issues.apache.org/jira/browse/GEODE-3217
 Project: Geode
  Issue Type: Bug
Reporter: Jared Stewart


The GFSH Query command is overly complex due to its implementation as a 
"multistep" command.  The current pagination is broken.  We should re-implement 
it as a standard (single-step) command.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (GEODE-3217) Reimplement GFSH Query as a single-step command

[Jared Stewart (JIRA)]

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

Jared Stewart updated GEODE-3217:
-
Component/s: gfsh

> Reimplement GFSH Query as a single-step command
> ---
>
> Key: GEODE-3217
> URL: https://issues.apache.org/jira/browse/GEODE-3217
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Reporter: Jared Stewart
>
> The GFSH Query command is overly complex due to its implementation as a 
> "multistep" command.  The current pagination is broken.  We should 
> re-implement it as a standard (single-step) command.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-2920) secure disk-store as a resource

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2920:


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

GEODE-2920: added security tests for create diskstore and create persistent 
region.


> secure disk-store as a resource
> ---
>
> Key: GEODE-2920
> URL: https://issues.apache.org/jira/browse/GEODE-2920
> Project: Geode
>  Issue Type: Sub-task
>  Components: security
>Reporter: Swapnil Bawaskar
>
> Treat DISK as a CLUSTER resource so that administrators can control the 
> ability to manage diskstores/create regions that will write to disk stores.
> Only a user with CLUSTER:MANAGE:DISK should be able to run the following gfsh 
> commands:
> {noformat}
> create disk-store
> alter disk-store
> compact disk-store
> destroy disk-store
> revoke missing-disk-store
> {noformat}
> And the following JMX bean methods:
> {noformat}
> DiskStoreMXBean.forceCompaction
> DiskStoreMXBean.flush
> DiskStoreMXBean.forceRoll
> DiskStoreMXBean.setDiskUsageCriticalPercentage
> DiskStoreMXBean.setDiskUsageWarningPercentage
> DistributedSystemMXBean.revokeMissingDiskStores
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (GEODE-3216) The new oplog creation adds the current oplog for compation before creating the new oplog.

[Anilkumar Gingade (JIRA)]

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

Anilkumar Gingade updated GEODE-3216:
-
Affects Version/s: 1.3.0

> The new oplog creation adds the current oplog for compation before creating 
> the new oplog.
> --
>
> Key: GEODE-3216
> URL: https://issues.apache.org/jira/browse/GEODE-3216
> Project: Geode
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 1.3.0
>Reporter: Anilkumar Gingade
>
> The new oplog creation logic adds the current oplog for compaction, before 
> creating the new oplog. If there is any failure with the new oplog creation, 
> the compactor may have started compacting the old oplog; which could result 
> in ticket# GEODE-3215. During new oplog creating its better to add the 
> old/current oplog for compaction after successfully creating the new oplog.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (GEODE-3215) Failure during oplog (.crf) creation does not clean up other resources (.drf) created.

[Anilkumar Gingade (JIRA)]

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

Anilkumar Gingade updated GEODE-3215:
-
Affects Version/s: 1.3.0

> Failure during oplog (.crf) creation does not clean up other resources (.drf) 
> created.
> --
>
> Key: GEODE-3215
> URL: https://issues.apache.org/jira/browse/GEODE-3215
> Project: Geode
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 1.3.0
>Reporter: Anilkumar Gingade
>
> As part of oplog creation, system generates, .drf, .crf files. It creates 
> .drf first and later .crf, during .crf creating if there is any failure 
> (preBlow) , it does not delete the .drf file. 
> In case of multiple disk directories, this will result in multiple .drf file 
> to be created, when concurrent compaction in progress. This results in 
> recovery failure with "Both the crf and drf for this oplog should be in the 
> same directory."



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (GEODE-3215) Failure during oplog (.crf) creation does not clean up other resources (.drf) created.

[Anilkumar Gingade (JIRA)]

Anilkumar Gingade created GEODE-3215:


 Summary: Failure during oplog (.crf) creation does not clean up 
other resources (.drf) created.
 Key: GEODE-3215
 URL: https://issues.apache.org/jira/browse/GEODE-3215
 Project: Geode
  Issue Type: Bug
  Components: persistence
Reporter: Anilkumar Gingade


As part of oplog creation, system generates, .drf, .crf files. It creates .drf 
first and later .crf, during .crf creating if there is any failure (preBlow) , 
it does not delete the .drf file. 

In case of multiple disk directories, this will result in multiple .drf file to 
be created, when concurrent compaction in progress. This results in recovery 
failure with "Both the crf and drf for this oplog should be in the same 
directory."



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (GEODE-3212) Spike: How to migrate non persistent region to persistent region without data loss

[Fred Krone (JIRA)]

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

Fred Krone updated GEODE-3212:
--
Description: 
Context
For releases with persistence support a user would have an option to enable 
that with new regions. We need to understand how users can migrate old regions 
and change their type?

Also, how can we switch on persistence with SSC region which is their internal 
region?

Question:
Assume I upgrade a version 1.1.x cluster with both an ssc and a non-ssc region. 
I want to upgrade versions and persist both regions, what steps are necessary?

Steps:
manually migrate non-ssc
manually migrate ssc
manually migrate when there is non-persisted pdx? (this might change is we can 
gaurantee pdx has been persisted)
capture all steps

Requesting one Storage engineer to pair for the day.  
This ticket may generate other tickets for Storage. 

  was:
Context
For releases with persistence support a customer would have an option to enable 
that with new regions. We need to understand how users can migrate old regions 
and change their type?

Also, how can we switch on persistence with SSC region which is their internal 
region?

Question:
Assume I upgrade a version 1.1.x cluster with both an ssc and a non-ssc region. 
I want to upgrade versions and persist both regions, what steps are necessary?

Steps:
manually migrate non-ssc
manually migrate ssc
manually migrate when there is non-persisted pdx? (this might change is we can 
gaurantee pdx has been persisted)
capture all steps

Requesting one Storage engineer to pair for the day.  
This ticket may generate other tickets for Storage. 


> Spike: How to migrate non persistent region to persistent region without data 
> loss
> --
>
> Key: GEODE-3212
> URL: https://issues.apache.org/jira/browse/GEODE-3212
> Project: Geode
>  Issue Type: Task
>  Components: persistence
>Reporter: Fred Krone
>
> Context
> For releases with persistence support a user would have an option to enable 
> that with new regions. We need to understand how users can migrate old 
> regions and change their type?
> Also, how can we switch on persistence with SSC region which is their 
> internal region?
> Question:
> Assume I upgrade a version 1.1.x cluster with both an ssc and a non-ssc 
> region. I want to upgrade versions and persist both regions, what steps are 
> necessary?
> Steps:
> manually migrate non-ssc
> manually migrate ssc
> manually migrate when there is non-persisted pdx? (this might change is we 
> can gaurantee pdx has been persisted)
> capture all steps
> Requesting one Storage engineer to pair for the day.  
> This ticket may generate other tickets for Storage. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (GEODE-3212) Spike: How to migrate non persistent region to persistent region without data loss

[Fred Krone (JIRA)]

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

Fred Krone updated GEODE-3212:
--
Description: 
Context
For releases with persistence support a customer would have an option to enable 
that with new regions. We need to understand how users can migrate old regions 
and change their type?

Also, how can we switch on persistence with SSC region which is their internal 
region?

Question:
Assume I upgrade a version 1.1.x cluster with both an ssc and a non-ssc region. 
I want to upgrade versions and persist both regions, what steps are necessary?

Steps:
manually migrate non-ssc
manually migrate ssc
manually migrate when there is non-persisted pdx? (this might change is we can 
gaurantee pdx has been persisted)
capture all steps

Requesting one Storage engineer to pair for the day.  
This ticket may generate other tickets for Storage. 

  was:
Context
After PCC releases with persistence support a customer would have an option to 
enable that with new regions. We need to understand how users can migrate old 
regions and change their type?

Also, how can PCC switch on persistence with SSC region which is their internal 
region?

Question:
Assume I have a PCC version 1.1.x cluster with both an ssc and a non-ssc 
region. I want to upgrade to PCC 1.2 and persist both regions, what steps are 
necessary?

Steps:
manually migrate non-ssc
manually migrate ssc
manually migrate when there is non-persisted pdx? (this might change is we can 
gaurantee pdx has been persisted)
capture all steps

PCC is requesting one Storage engineer to pair for the day.  
This ticket may generate other tickets for Storage. 


> Spike: How to migrate non persistent region to persistent region without data 
> loss
> --
>
> Key: GEODE-3212
> URL: https://issues.apache.org/jira/browse/GEODE-3212
> Project: Geode
>  Issue Type: Task
>  Components: persistence
>Reporter: Fred Krone
>
> Context
> For releases with persistence support a customer would have an option to 
> enable that with new regions. We need to understand how users can migrate old 
> regions and change their type?
> Also, how can we switch on persistence with SSC region which is their 
> internal region?
> Question:
> Assume I upgrade a version 1.1.x cluster with both an ssc and a non-ssc 
> region. I want to upgrade versions and persist both regions, what steps are 
> necessary?
> Steps:
> manually migrate non-ssc
> manually migrate ssc
> manually migrate when there is non-persisted pdx? (this might change is we 
> can gaurantee pdx has been persisted)
> capture all steps
> Requesting one Storage engineer to pair for the day.  
> This ticket may generate other tickets for Storage. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3212) Spike: How to migrate non persistent region to persistent region without data loss

[Fred Krone (JIRA)]

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

Fred Krone commented on GEODE-3212:
---

You're right.  

> Spike: How to migrate non persistent region to persistent region without data 
> loss
> --
>
> Key: GEODE-3212
> URL: https://issues.apache.org/jira/browse/GEODE-3212
> Project: Geode
>  Issue Type: Task
>  Components: persistence
>Reporter: Fred Krone
>
> Context
> After PCC releases with persistence support a customer would have an option 
> to enable that with new regions. We need to understand how users can migrate 
> old regions and change their type?
> Also, how can PCC switch on persistence with SSC region which is their 
> internal region?
> Question:
> Assume I have a PCC version 1.1.x cluster with both an ssc and a non-ssc 
> region. I want to upgrade to PCC 1.2 and persist both regions, what steps are 
> necessary?
> Steps:
> manually migrate non-ssc
> manually migrate ssc
> manually migrate when there is non-persisted pdx? (this might change is we 
> can gaurantee pdx has been persisted)
> capture all steps
> PCC is requesting one Storage engineer to pair for the day.  
> This ticket may generate other tickets for Storage. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (GEODE-3212) Spike: How to migrate non persistent region to persistent region without data loss

[Fred Krone (JIRA)]

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

Fred Krone updated GEODE-3212:
--
Summary: Spike: How to migrate non persistent region to persistent region 
without data loss  (was: Spike: How to migrate non persistent region to 
persistent region without data loss.)

> Spike: How to migrate non persistent region to persistent region without data 
> loss
> --
>
> Key: GEODE-3212
> URL: https://issues.apache.org/jira/browse/GEODE-3212
> Project: Geode
>  Issue Type: Task
>  Components: persistence
>Reporter: Fred Krone
>
> Context
> After PCC releases with persistence support a customer would have an option 
> to enable that with new regions. We need to understand how users can migrate 
> old regions and change their type?
> Also, how can PCC switch on persistence with SSC region which is their 
> internal region?
> Question:
> Assume I have a PCC version 1.1.x cluster with both an ssc and a non-ssc 
> region. I want to upgrade to PCC 1.2 and persist both regions, what steps are 
> necessary?
> Steps:
> manually migrate non-ssc
> manually migrate ssc
> manually migrate when there is non-persisted pdx? (this might change is we 
> can gaurantee pdx has been persisted)
> capture all steps
> PCC is requesting one Storage engineer to pair for the day.  
> This ticket may generate other tickets for Storage. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (GEODE-3214) Remove Multistep Commands

[Jared Stewart (JIRA)]

Jared Stewart created GEODE-3214:


 Summary: Remove Multistep Commands
 Key: GEODE-3214
 URL: https://issues.apache.org/jira/browse/GEODE-3214
 Project: Geode
  Issue Type: Bug
  Components: gfsh
Reporter: Jared Stewart


The implementation of Multistep commands is needlessly complex and buggy.  We 
should reimplement gfsh "query" as a normal command and remove the code for 
Multistep.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (GEODE-3213) Refactor Protobuf Serialization Implemenation

[Udo Kohlmeyer (JIRA)]

Udo Kohlmeyer created GEODE-3213:


 Summary: Refactor Protobuf Serialization Implemenation
 Key: GEODE-3213
 URL: https://issues.apache.org/jira/browse/GEODE-3213
 Project: Geode
  Issue Type: Improvement
  Components: client/server, serialization
Reporter: Udo Kohlmeyer


In the Protobuf serialization implementation, there are some refactorings we 
want to make:
* OperationHandlers take OperationRequest and OperationResponse message, not 
the parent Request/Response Object
* A generic flow needs to be implemented that all OperationHandlers follow. No 
bespoke flows for any OperationHandlers... way too much maintenance
* Use Functional semantics to configure the functionality to extract 
OperationRequest from Request (per OperationHandler)
* Use Functional semantics to configure the functionality to populate 
OperationResponse in the relevant Response
* Have generic Error Handling framework to populate "known" errors and error 
codes



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (GEODE-3193) locator pid file is removed even if there was a problem while shutting down

[Swapnil Bawaskar (JIRA)]

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

Swapnil Bawaskar updated GEODE-3193:

Component/s: (was: locator)
 gfsh

> locator pid file is removed even if there was a problem while shutting down
> ---
>
> Key: GEODE-3193
> URL: https://issues.apache.org/jira/browse/GEODE-3193
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Affects Versions: 1.0.0-incubating, 1.1.0, 1.1.1, 1.2.0
>Reporter: Swapnil Bawaskar
>
> The pid file should not be cleaned up if the locator process failed to 
> shutdown with a problem like GEODE-3191.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (GEODE-3191) NPE in pulse prevents locator shutdown

[Swapnil Bawaskar (JIRA)]

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

Swapnil Bawaskar closed GEODE-3191.
---

> NPE in pulse prevents locator shutdown
> --
>
> Key: GEODE-3191
> URL: https://issues.apache.org/jira/browse/GEODE-3191
> Project: Geode
>  Issue Type: Bug
>  Components: pulse
>Reporter: Swapnil Bawaskar
> Fix For: 1.2.0
>
>
> We found that when there is an open connection to pulse `gfsh stop locator` 
> fails to correctly stop the locator process. In the locator logs we see:
> {noformat}
> [warning 2017/07/11 21:13:44.713 UTC 
> locator-ced56c23-6523-413c-9b24-dadf10683b89  10.0.8.7> tid=0xe] Failed to stop the HTTP service because: null
> java.lang.NullPointerException
>   at 
> org.apache.geode.tools.pulse.internal.data.Repository.removeAllClusters(Repository.java:226)
>   at 
> org.apache.geode.tools.pulse.internal.PulseAppListener.contextDestroyed(PulseAppListener.java:83)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.callContextDestroyed(ContextHandler.java:843)
>   at 
> org.eclipse.jetty.servlet.ServletContextHandler.callContextDestroyed(ServletContextHandler.java:543)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.stopContext(ContextHandler.java:824)
>   at 
> org.eclipse.jetty.servlet.ServletContextHandler.stopContext(ServletContextHandler.java:353)
>   at 
> org.eclipse.jetty.webapp.WebAppContext.stopWebapp(WebAppContext.java:1385)
>   at 
> org.eclipse.jetty.webapp.WebAppContext.stopContext(WebAppContext.java:1349)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doStop(ContextHandler.java:872)
>   at 
> org.eclipse.jetty.servlet.ServletContextHandler.doStop(ServletContextHandler.java:269)
>   at org.eclipse.jetty.webapp.WebAppContext.doStop(WebAppContext.java:541)
>   at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
>   at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.stop(ContainerLifeCycle.java:143)
>   at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStop(ContainerLifeCycle.java:161)
>   at 
> org.eclipse.jetty.server.handler.AbstractHandler.doStop(AbstractHandler.java:73)
>   at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
>   at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.stop(ContainerLifeCycle.java:143)
>   at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStop(ContainerLifeCycle.java:161)
>   at 
> org.eclipse.jetty.server.handler.AbstractHandler.doStop(AbstractHandler.java:73)
>   at org.eclipse.jetty.server.Server.doStop(Server.java:476)
>   at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
>   at 
> org.apache.geode.management.internal.ManagementAgent.stopHttpService(ManagementAgent.java:334)
>   at 
> org.apache.geode.management.internal.ManagementAgent.stopAgent(ManagementAgent.java:157)
>   at 
> org.apache.geode.management.internal.SystemManagementService.close(SystemManagementService.java:265)
>   at 
> org.apache.geode.management.internal.beans.ManagementAdapter.handleCacheRemoval(ManagementAdapter.java:735)
>   at 
> org.apache.geode.management.internal.beans.ManagementListener.handleEvent(ManagementListener.java:117)
>   at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.notifyResourceEventListeners(InternalDistributedSystem.java:2162)
>   at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.handleResourceEvent(InternalDistributedSystem.java:535)
>   at 
> org.apache.geode.internal.cache.GemFireCacheImpl.close(GemFireCacheImpl.java:2145)
>   at 
> org.apache.geode.internal.cache.GemFireCacheImpl.close(GemFireCacheImpl.java:1988)
>   at 
> org.apache.geode.internal.cache.GemFireCacheImpl.close(GemFireCacheImpl.java:1984)
>   at 
> org.apache.geode.distributed.internal.InternalLocator.handleShutdown(InternalLocator.java:984)
>   at 
> org.apache.geode.distributed.internal.InternalLocator.access$500(InternalLocator.java:103)
>   at 
> org.apache.geode.distributed.internal.InternalLocator$PrimaryHandler.shutDown(InternalLocator.java:1359)
>   at 
> org.apache.geode.distributed.internal.tcpserver.TcpServer.run(TcpServer.java:324)
>   at 
> org.apache.geode.distributed.internal.tcpserver.TcpServer$2.run(TcpServer.java:227)
> [error 2017/07/11 21:13:44.714 UTC 
> locator-ced56c23-6523-413c-9b24-dadf10683b89  10.0.8.7> tid=0xe] Failed to properly release resources held by the HTTP 
> service: !STOPPED
> java.lang.IllegalStateException: !STOPPED
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.destroy(HandlerWrapper.java:134)
>   at 
> 

[jira] [Resolved] (GEODE-3191) NPE in pulse prevents locator shutdown

[Swapnil Bawaskar (JIRA)]

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

Swapnil Bawaskar resolved GEODE-3191.
-
Resolution: Duplicate

> NPE in pulse prevents locator shutdown
> --
>
> Key: GEODE-3191
> URL: https://issues.apache.org/jira/browse/GEODE-3191
> Project: Geode
>  Issue Type: Bug
>  Components: pulse
>Reporter: Swapnil Bawaskar
> Fix For: 1.2.0
>
>
> We found that when there is an open connection to pulse `gfsh stop locator` 
> fails to correctly stop the locator process. In the locator logs we see:
> {noformat}
> [warning 2017/07/11 21:13:44.713 UTC 
> locator-ced56c23-6523-413c-9b24-dadf10683b89  10.0.8.7> tid=0xe] Failed to stop the HTTP service because: null
> java.lang.NullPointerException
>   at 
> org.apache.geode.tools.pulse.internal.data.Repository.removeAllClusters(Repository.java:226)
>   at 
> org.apache.geode.tools.pulse.internal.PulseAppListener.contextDestroyed(PulseAppListener.java:83)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.callContextDestroyed(ContextHandler.java:843)
>   at 
> org.eclipse.jetty.servlet.ServletContextHandler.callContextDestroyed(ServletContextHandler.java:543)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.stopContext(ContextHandler.java:824)
>   at 
> org.eclipse.jetty.servlet.ServletContextHandler.stopContext(ServletContextHandler.java:353)
>   at 
> org.eclipse.jetty.webapp.WebAppContext.stopWebapp(WebAppContext.java:1385)
>   at 
> org.eclipse.jetty.webapp.WebAppContext.stopContext(WebAppContext.java:1349)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doStop(ContextHandler.java:872)
>   at 
> org.eclipse.jetty.servlet.ServletContextHandler.doStop(ServletContextHandler.java:269)
>   at org.eclipse.jetty.webapp.WebAppContext.doStop(WebAppContext.java:541)
>   at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
>   at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.stop(ContainerLifeCycle.java:143)
>   at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStop(ContainerLifeCycle.java:161)
>   at 
> org.eclipse.jetty.server.handler.AbstractHandler.doStop(AbstractHandler.java:73)
>   at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
>   at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.stop(ContainerLifeCycle.java:143)
>   at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStop(ContainerLifeCycle.java:161)
>   at 
> org.eclipse.jetty.server.handler.AbstractHandler.doStop(AbstractHandler.java:73)
>   at org.eclipse.jetty.server.Server.doStop(Server.java:476)
>   at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
>   at 
> org.apache.geode.management.internal.ManagementAgent.stopHttpService(ManagementAgent.java:334)
>   at 
> org.apache.geode.management.internal.ManagementAgent.stopAgent(ManagementAgent.java:157)
>   at 
> org.apache.geode.management.internal.SystemManagementService.close(SystemManagementService.java:265)
>   at 
> org.apache.geode.management.internal.beans.ManagementAdapter.handleCacheRemoval(ManagementAdapter.java:735)
>   at 
> org.apache.geode.management.internal.beans.ManagementListener.handleEvent(ManagementListener.java:117)
>   at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.notifyResourceEventListeners(InternalDistributedSystem.java:2162)
>   at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.handleResourceEvent(InternalDistributedSystem.java:535)
>   at 
> org.apache.geode.internal.cache.GemFireCacheImpl.close(GemFireCacheImpl.java:2145)
>   at 
> org.apache.geode.internal.cache.GemFireCacheImpl.close(GemFireCacheImpl.java:1988)
>   at 
> org.apache.geode.internal.cache.GemFireCacheImpl.close(GemFireCacheImpl.java:1984)
>   at 
> org.apache.geode.distributed.internal.InternalLocator.handleShutdown(InternalLocator.java:984)
>   at 
> org.apache.geode.distributed.internal.InternalLocator.access$500(InternalLocator.java:103)
>   at 
> org.apache.geode.distributed.internal.InternalLocator$PrimaryHandler.shutDown(InternalLocator.java:1359)
>   at 
> org.apache.geode.distributed.internal.tcpserver.TcpServer.run(TcpServer.java:324)
>   at 
> org.apache.geode.distributed.internal.tcpserver.TcpServer$2.run(TcpServer.java:227)
> [error 2017/07/11 21:13:44.714 UTC 
> locator-ced56c23-6523-413c-9b24-dadf10683b89  10.0.8.7> tid=0xe] Failed to properly release resources held by the HTTP 
> service: !STOPPED
> java.lang.IllegalStateException: !STOPPED
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.destroy(HandlerWrapper.java:134)
>   at 
> 

[jira] [Reopened] (GEODE-3191) NPE in pulse prevents locator shutdown

[Swapnil Bawaskar (JIRA)]

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

Swapnil Bawaskar reopened GEODE-3191:
-

> NPE in pulse prevents locator shutdown
> --
>
> Key: GEODE-3191
> URL: https://issues.apache.org/jira/browse/GEODE-3191
> Project: Geode
>  Issue Type: Bug
>  Components: pulse
>Reporter: Swapnil Bawaskar
> Fix For: 1.2.0
>
>
> We found that when there is an open connection to pulse `gfsh stop locator` 
> fails to correctly stop the locator process. In the locator logs we see:
> {noformat}
> [warning 2017/07/11 21:13:44.713 UTC 
> locator-ced56c23-6523-413c-9b24-dadf10683b89  10.0.8.7> tid=0xe] Failed to stop the HTTP service because: null
> java.lang.NullPointerException
>   at 
> org.apache.geode.tools.pulse.internal.data.Repository.removeAllClusters(Repository.java:226)
>   at 
> org.apache.geode.tools.pulse.internal.PulseAppListener.contextDestroyed(PulseAppListener.java:83)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.callContextDestroyed(ContextHandler.java:843)
>   at 
> org.eclipse.jetty.servlet.ServletContextHandler.callContextDestroyed(ServletContextHandler.java:543)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.stopContext(ContextHandler.java:824)
>   at 
> org.eclipse.jetty.servlet.ServletContextHandler.stopContext(ServletContextHandler.java:353)
>   at 
> org.eclipse.jetty.webapp.WebAppContext.stopWebapp(WebAppContext.java:1385)
>   at 
> org.eclipse.jetty.webapp.WebAppContext.stopContext(WebAppContext.java:1349)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doStop(ContextHandler.java:872)
>   at 
> org.eclipse.jetty.servlet.ServletContextHandler.doStop(ServletContextHandler.java:269)
>   at org.eclipse.jetty.webapp.WebAppContext.doStop(WebAppContext.java:541)
>   at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
>   at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.stop(ContainerLifeCycle.java:143)
>   at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStop(ContainerLifeCycle.java:161)
>   at 
> org.eclipse.jetty.server.handler.AbstractHandler.doStop(AbstractHandler.java:73)
>   at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
>   at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.stop(ContainerLifeCycle.java:143)
>   at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStop(ContainerLifeCycle.java:161)
>   at 
> org.eclipse.jetty.server.handler.AbstractHandler.doStop(AbstractHandler.java:73)
>   at org.eclipse.jetty.server.Server.doStop(Server.java:476)
>   at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
>   at 
> org.apache.geode.management.internal.ManagementAgent.stopHttpService(ManagementAgent.java:334)
>   at 
> org.apache.geode.management.internal.ManagementAgent.stopAgent(ManagementAgent.java:157)
>   at 
> org.apache.geode.management.internal.SystemManagementService.close(SystemManagementService.java:265)
>   at 
> org.apache.geode.management.internal.beans.ManagementAdapter.handleCacheRemoval(ManagementAdapter.java:735)
>   at 
> org.apache.geode.management.internal.beans.ManagementListener.handleEvent(ManagementListener.java:117)
>   at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.notifyResourceEventListeners(InternalDistributedSystem.java:2162)
>   at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.handleResourceEvent(InternalDistributedSystem.java:535)
>   at 
> org.apache.geode.internal.cache.GemFireCacheImpl.close(GemFireCacheImpl.java:2145)
>   at 
> org.apache.geode.internal.cache.GemFireCacheImpl.close(GemFireCacheImpl.java:1988)
>   at 
> org.apache.geode.internal.cache.GemFireCacheImpl.close(GemFireCacheImpl.java:1984)
>   at 
> org.apache.geode.distributed.internal.InternalLocator.handleShutdown(InternalLocator.java:984)
>   at 
> org.apache.geode.distributed.internal.InternalLocator.access$500(InternalLocator.java:103)
>   at 
> org.apache.geode.distributed.internal.InternalLocator$PrimaryHandler.shutDown(InternalLocator.java:1359)
>   at 
> org.apache.geode.distributed.internal.tcpserver.TcpServer.run(TcpServer.java:324)
>   at 
> org.apache.geode.distributed.internal.tcpserver.TcpServer$2.run(TcpServer.java:227)
> [error 2017/07/11 21:13:44.714 UTC 
> locator-ced56c23-6523-413c-9b24-dadf10683b89  10.0.8.7> tid=0xe] Failed to properly release resources held by the HTTP 
> service: !STOPPED
> java.lang.IllegalStateException: !STOPPED
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.destroy(HandlerWrapper.java:134)
>   at 
> 

[jira] [Resolved] (GEODE-3191) NPE in pulse prevents locator shutdown

[Swapnil Bawaskar (JIRA)]

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

Swapnil Bawaskar resolved GEODE-3191.
-
   Resolution: Duplicate
Fix Version/s: 1.2.0

> NPE in pulse prevents locator shutdown
> --
>
> Key: GEODE-3191
> URL: https://issues.apache.org/jira/browse/GEODE-3191
> Project: Geode
>  Issue Type: Bug
>  Components: pulse
>Reporter: Swapnil Bawaskar
> Fix For: 1.2.0
>
>
> We found that when there is an open connection to pulse `gfsh stop locator` 
> fails to correctly stop the locator process. In the locator logs we see:
> {noformat}
> [warning 2017/07/11 21:13:44.713 UTC 
> locator-ced56c23-6523-413c-9b24-dadf10683b89  10.0.8.7> tid=0xe] Failed to stop the HTTP service because: null
> java.lang.NullPointerException
>   at 
> org.apache.geode.tools.pulse.internal.data.Repository.removeAllClusters(Repository.java:226)
>   at 
> org.apache.geode.tools.pulse.internal.PulseAppListener.contextDestroyed(PulseAppListener.java:83)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.callContextDestroyed(ContextHandler.java:843)
>   at 
> org.eclipse.jetty.servlet.ServletContextHandler.callContextDestroyed(ServletContextHandler.java:543)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.stopContext(ContextHandler.java:824)
>   at 
> org.eclipse.jetty.servlet.ServletContextHandler.stopContext(ServletContextHandler.java:353)
>   at 
> org.eclipse.jetty.webapp.WebAppContext.stopWebapp(WebAppContext.java:1385)
>   at 
> org.eclipse.jetty.webapp.WebAppContext.stopContext(WebAppContext.java:1349)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doStop(ContextHandler.java:872)
>   at 
> org.eclipse.jetty.servlet.ServletContextHandler.doStop(ServletContextHandler.java:269)
>   at org.eclipse.jetty.webapp.WebAppContext.doStop(WebAppContext.java:541)
>   at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
>   at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.stop(ContainerLifeCycle.java:143)
>   at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStop(ContainerLifeCycle.java:161)
>   at 
> org.eclipse.jetty.server.handler.AbstractHandler.doStop(AbstractHandler.java:73)
>   at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
>   at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.stop(ContainerLifeCycle.java:143)
>   at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStop(ContainerLifeCycle.java:161)
>   at 
> org.eclipse.jetty.server.handler.AbstractHandler.doStop(AbstractHandler.java:73)
>   at org.eclipse.jetty.server.Server.doStop(Server.java:476)
>   at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
>   at 
> org.apache.geode.management.internal.ManagementAgent.stopHttpService(ManagementAgent.java:334)
>   at 
> org.apache.geode.management.internal.ManagementAgent.stopAgent(ManagementAgent.java:157)
>   at 
> org.apache.geode.management.internal.SystemManagementService.close(SystemManagementService.java:265)
>   at 
> org.apache.geode.management.internal.beans.ManagementAdapter.handleCacheRemoval(ManagementAdapter.java:735)
>   at 
> org.apache.geode.management.internal.beans.ManagementListener.handleEvent(ManagementListener.java:117)
>   at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.notifyResourceEventListeners(InternalDistributedSystem.java:2162)
>   at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.handleResourceEvent(InternalDistributedSystem.java:535)
>   at 
> org.apache.geode.internal.cache.GemFireCacheImpl.close(GemFireCacheImpl.java:2145)
>   at 
> org.apache.geode.internal.cache.GemFireCacheImpl.close(GemFireCacheImpl.java:1988)
>   at 
> org.apache.geode.internal.cache.GemFireCacheImpl.close(GemFireCacheImpl.java:1984)
>   at 
> org.apache.geode.distributed.internal.InternalLocator.handleShutdown(InternalLocator.java:984)
>   at 
> org.apache.geode.distributed.internal.InternalLocator.access$500(InternalLocator.java:103)
>   at 
> org.apache.geode.distributed.internal.InternalLocator$PrimaryHandler.shutDown(InternalLocator.java:1359)
>   at 
> org.apache.geode.distributed.internal.tcpserver.TcpServer.run(TcpServer.java:324)
>   at 
> org.apache.geode.distributed.internal.tcpserver.TcpServer$2.run(TcpServer.java:227)
> [error 2017/07/11 21:13:44.714 UTC 
> locator-ced56c23-6523-413c-9b24-dadf10683b89  10.0.8.7> tid=0xe] Failed to properly release resources held by the HTTP 
> service: !STOPPED
> java.lang.IllegalStateException: !STOPPED
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.destroy(HandlerWrapper.java:134)
>   

[jira] [Commented] (GEODE-3141) New flow: GetRegion

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/geode/pull/630#discussion_r127756778
  
--- Diff: geode-protobuf/src/main/proto/region_API.proto ---
@@ -102,4 +102,14 @@ message GetRegionNamesRequest {
 
 message GetRegionNamesResponse {
 repeated string regions = 1;
-}
\ No newline at end of file
+}
+
+/* does a region exist? */
+message GetRegionRequest {
+string regionName = 1;
+}
+
+/* success will be true if the region exists */
--- End diff --

Did there used to be a success variable here?


> New flow: GetRegion
> ---
>
> Key: GEODE-3141
> URL: https://issues.apache.org/jira/browse/GEODE-3141
> Project: Geode
>  Issue Type: Sub-task
>  Components: client/server
>Reporter: Brian Baynes
>Assignee: Udo Kohlmeyer
>
> Users of the new client/server protocol need to be able to verify a region 
> exists in the cache. Implement GetRegion message/handler, returning boolean 
> success(/failure) based on the existence of a Region when passed a Region 
> name.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (GEODE-3134) LuceneCommandsSecurityDUnitTest fails with Anonymous User

[Jinmei Liao (JIRA)]

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

Jinmei Liao updated GEODE-3134:
---
Component/s: security

> LuceneCommandsSecurityDUnitTest fails with Anonymous User
> -
>
> Key: GEODE-3134
> URL: https://issues.apache.org/jira/browse/GEODE-3134
> Project: Geode
>  Issue Type: Bug
>  Components: security
>Reporter: Jinmei Liao
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (GEODE-2969) Meaningful exception information is stripped during exception handling

[Swapnil Bawaskar (JIRA)]

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

Swapnil Bawaskar updated GEODE-2969:

Component/s: (was: logging)
 gfsh

> Meaningful exception information is stripped during exception handling
> --
>
> Key: GEODE-2969
> URL: https://issues.apache.org/jira/browse/GEODE-2969
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Reporter: Patrick Rhomberg
>
> A number of contexts result in a less-than-meaningful message to log or 
> console of simply `null`.  For instance, running `gfsh status locator` prints 
> only `null`.
> This may be the result of exceptions being converted to exceptions of another 
> type or to error results, but in the process losing important information by 
> only passing `e.getMessage()` to the new type.  For instance, the above `gfsh 
> status locator` is failing with a `java.lang.NumberFormatException: null`, 
> but this exception is converted to `return 
> ResultBuilder.createUserErrorResult(e.getMessage());`  In this case, 
> `e.getMessage()` is `null`, where the more meaningful result is the type of 
> exception.
> A fix to this will likely close GEODE-2569



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (GEODE-3204) txApplyInvalidate in AbstractRegionMap on farside should not update the entry if it is a removed token

[Eric Shu (JIRA)]

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

Eric Shu resolved GEODE-3204.
-
   Resolution: Fixed
Fix Version/s: 1.3.0

> txApplyInvalidate in AbstractRegionMap on farside should not update the entry 
> if it is a removed token
> --
>
> Key: GEODE-3204
> URL: https://issues.apache.org/jira/browse/GEODE-3204
> Project: Geode
>  Issue Type: Bug
>  Components: transactions
>Affects Versions: 1.3.0
>Reporter: Eric Shu
>Assignee: Eric Shu
> Fix For: 1.3.0
>
>
> When tx invalidates on a region entry with Token.REMOVED_PHASE2 (without 
> forceNewEntry), it could update a region entry going to be removed from the 
> AbstractRegionMap. In some race cases, a new tx create could be lost, as a 
> txApplyPut could update on the entry with INVALIDATE token without executing 
> the putEntryIfAbsent (does not recognize the entry is being removed from the 
> AbstractRegionMap, as the entry is not Token.REMOVED_PHASE2).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3204) txApplyInvalidate in AbstractRegionMap on farside should not update the entry if it is a removed token

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-3204:


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

GEODE-3204: txApplyInvalidate in AbstractRegionMap on farside does not update 
on a region entry with removed token.


> txApplyInvalidate in AbstractRegionMap on farside should not update the entry 
> if it is a removed token
> --
>
> Key: GEODE-3204
> URL: https://issues.apache.org/jira/browse/GEODE-3204
> Project: Geode
>  Issue Type: Bug
>  Components: transactions
>Affects Versions: 1.3.0
>Reporter: Eric Shu
>Assignee: Eric Shu
>
> When tx invalidates on a region entry with Token.REMOVED_PHASE2 (without 
> forceNewEntry), it could update a region entry going to be removed from the 
> AbstractRegionMap. In some race cases, a new tx create could be lost, as a 
> txApplyPut could update on the entry with INVALIDATE token without executing 
> the putEntryIfAbsent (does not recognize the entry is being removed from the 
> AbstractRegionMap, as the entry is not Token.REMOVED_PHASE2).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)