[jira] [Created] (GEODE-3234) FunctionAccessController's argsInBody is always empty string
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
[ 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
[ https://issues.apache.org/jira/browse/GEODE-3233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Created] (GEODE-3233) Examples distribution files need apache prefix
Anthony Baker created GEODE-3233: Summary: 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-2860) refactor EventTracker to be on DistributedRegion instead of LocalRegion
[ https://issues.apache.org/jira/browse/GEODE-2860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16090852#comment-16090852 ] ASF subversion and git services commented on GEODE-2860: Commit 9e7696a64621cc05122e065e492cc5e000e96622 in geode's branch refs/heads/develop from [~nreich] [ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=9e7696a ] GEODE-2860: Refactor use of EventTracker * change EventTracker to an interface with two implementations * move as much logic out of LocalRegion down into subclasses that make use EventTracker * move and refactor static inner classes in EventTracker into own class files * migrate some of event-focused classes into a new sub package * add tests for existing logic from EventTracker This closes #638 > refactor EventTracker to be on DistributedRegion instead of LocalRegion > --- > > Key: GEODE-2860 > URL: https://issues.apache.org/jira/browse/GEODE-2860 > Project: Geode > Issue Type: Improvement > Components: regions >Reporter: Darrel Schneider >Assignee: Nick Reich > Labels: storage_3 > > Currently LocalRegion has a non-final field named "eventTracker". It is > initialized in a method named createEventTracker which does nothing on > LocalRegion but is implemented on DistributedRegion and BucketRegion to > initialize the eventTracker field. > I think things would be clearer if this field was moved to DistributedRegion. > All the code on LocalRegion that currently tests for a non-null eventTracker > can be changed to do nothing and overridden on DistributedRegion to use its > eventTracker. DistributedRegion can make this field final and always set it > in its constructor. Since BucketRegion extends DistributedRegion it does not > to do anything (it currently implements createEventTracker but that was not > needed since it inherits the same impl from DistributedRegion). -- 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
[ https://issues.apache.org/jira/browse/GEODE-3186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/GEODE-3232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 strea
[jira] [Commented] (GEODE-3232) Race condition serializing FilterProfile
[ https://issues.apache.org/jira/browse/GEODE-3232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 > org.apache.geode.internal.InternalDataSerializer.invokeFromData(InternalDat
[jira] [Updated] (GEODE-2920) secure disk-store as a resource
[ https://issues.apache.org/jira/browse/GEODE-2920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karen Smoler Miller updated GEODE-2920: --- Component/s: docs > 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: docs, 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] [Created] (GEODE-3232) Race condition serializing FilterProfile
Dan Smith created GEODE-3232: Summary: 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 :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 gets an iterator on the set. Between those two calls the set could be modified. I think the code needs to do something like this for all of these sets to be threadsafe: {code} InternalDataSerializer.writeSetOfLongs(this.allKeyClients.getSnapshot(), this.clientMap.hasLongID, out); {code} -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (GEODE-3185) CI failure (windows): org.apache.geode.internal.cache.BackupJUnitTest, 3 tests failing with java.lang.AssertionError: Null entry
[ https://issues.apache.org/jira/browse/GEODE-3185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-3185) CI failure (windows): org.apache.geode.internal.cache.BackupJUnitTest, 3 tests failing with java.lang.AssertionError: Null entry
[ https://issues.apache.org/jira/browse/GEODE-3185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16090793#comment-16090793 ] Darrel Schneider commented on GEODE-3185: - It is possible that the two tests that are failing that call backupAndRecover are failing because the restore.bat file is not working. It has a hardcoded path to Robocopy.exe that may not be correct on these machines. If the hardcoded path was changed to be just "robocopy" then the backupAndRecover tests might work. Note that the test code that invokes restore.bat ignores any exit code on Windows so if this script fails the test could not tell (see org.apache.geode.internal.cache.BackupJUnitTest.execute(File, boolean)). It does print the output of the script to System.out prefixed by "OUTPUT:" so if this could be located it might give some clues about what is going wrong. > 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
[ https://issues.apache.org/jira/browse/GEODE-3187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/GEODE-2226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 org.apache.geode.modules.session.internal.filter.SessionReplicationIntegrationJUnitTest.testSessionRemain
[jira] [Updated] (GEODE-2226) SessionReplicationIntegrationJUnitTest is broken on Windows
[ 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 > org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandl
[jira] [Assigned] (GEODE-3230) Delete unused commands in CliStrings and refactor redundant commands
[ 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
[ https://issues.apache.org/jira/browse/GEODE-3112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/GEODE-3112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/GEODE-3180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/GEODE-3230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emily Yeh updated GEODE-3230: - Description: 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}}. was: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. > 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. > 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] [Updated] (GEODE-3230) Delete unused commands in CliStrings and refactor redundant commands
[ 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-3231) Do not have Server/LocatorStarterRule put logs in a log file by default.
Jinmei Liao created GEODE-3231: -- Summary: Do not have Server/LocatorStarterRule put logs in a log file by default. Key: GEODE-3231 URL: https://issues.apache.org/jira/browse/GEODE-3231 Project: Geode Issue Type: Bug Reporter: Jinmei Liao Currently, these rules have LOG_FILE defined by default, thus logs won't go into the console but into a file. Need to have the logs go to the console by default, and to file only needed. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (GEODE-3230) Delete unused commands in CliStrings
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
[ https://issues.apache.org/jira/browse/GEODE-3199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/GEODE-3202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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.
[ https://issues.apache.org/jira/browse/GEODE-3168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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
[ https://issues.apache.org/jira/browse/GEODE-3141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/GEODE-3166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-3168) Fix CLI projects and tests.
[ https://issues.apache.org/jira/browse/GEODE-3168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16090473#comment-16090473 ] ASF subversion and git services commented on GEODE-3168: Commit 351fa598c15bd6ed9942e3fdcb27d5fda8810faa in geode-native's branch refs/heads/develop from Jacob Barrett [ https://git-wip-us.apache.org/repos/asf?p=geode-native.git;h=351fa59 ] GEODE-3168: Fixes CLI tests in Release mode - Disabled all optimization for static lib > 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] [Commented] (GEODE-3048) Tests that require the Gradle test runner should fail descriptively when run through Intellij
[ https://issues.apache.org/jira/browse/GEODE-3048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/GEODE-2203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/GEODE-3141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Updated] (GEODE-3225) GetRegionInfo Specification Definition
[ https://issues.apache.org/jira/browse/GEODE-3225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer updated GEODE-3225: - Summary: GetRegionInfo Specification Definition (was: GetRegion Specification Definition) > GetRegionInfo 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] [Created] (GEODE-3229) The PutAllOperationHandler is currently stateful. Needs to be stateless
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
[ 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 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 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
[ https://issues.apache.org/jira/browse/GEODE-3207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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
[ https://issues.apache.org/jira/browse/GEODE-2189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 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 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
[ 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
[ 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 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 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-3221) GetAll Specification Definition
Udo Kohlmeyer created GEODE-3221: Summary: GetAll Specification Definition Key: GEODE-3221 URL: https://issues.apache.org/jira/browse/GEODE-3221 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 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 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
[ 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 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 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
[ https://issues.apache.org/jira/browse/GEODE-3213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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
[ https://issues.apache.org/jira/browse/GEODE-3153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/GEODE-3139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/GEODE-3172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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(InitialImageOper
[jira] [Commented] (GEODE-3175) backward-compatibility tests fail with bad classpath
[ https://issues.apache.org/jira/browse/GEODE-3175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16090200#comment-16090200 ] ASF subversion and git services commented on GEODE-3175: Commit 964f2749065ce9c6898fd27983b43f1bd9fc77d0 in geode's branch refs/heads/master from [~bschuchardt] [ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=964f274 ] GEODE-3175 backward-compatibility tests fail with bad classpath temporarily backing out removal of current-version class files and resources to observe build behavior. > backward-compatibility tests fail with bad classpath > > > Key: GEODE-3175 > URL: https://issues.apache.org/jira/browse/GEODE-3175 > Project: Geode > Issue Type: Bug > Components: tests >Reporter: Bruce Schuchardt >Assignee: Bruce Schuchardt > > Some test runs are failing to start up a JVM running an old version of Geode. > RollingUpgradeDUnitTest was trying to boot a VM running 110 and the > classpath logged by ProcessManager was for 100 & the VM didn't launch > correctly. > {noformat} > org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeDUnitTest > > testRollServersOnPersistentRegion_dataserializable[2] FAILED > java.lang.RuntimeException: VMs did not start up within 120 seconds > at > org.apache.geode.test.dunit.standalone.DUnitLauncher$Master.bounce(DUnitLauncher.java:440) > at > org.apache.geode.test.dunit.standalone.StandAloneDUnitEnv.bounce(StandAloneDUnitEnv.java:64) > at org.apache.geode.test.dunit.VM.bounce(VM.java:407) > at > org.apache.geode.test.dunit.standalone.DUnitLauncher$DUnitHost.getVM(DUnitLauncher.java:495) > at > org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeDUnitTest.doTestRollAll(RollingUpgradeDUnitTest.java:144) > at > org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeDUnitTest.testRollServersOnPersistentRegion_dataserializable(RollingUpgradeDUnitTest.java:134) > org.apache.geode.test.dunit.RMIException: While invoking > org.apache.geode.test.dunit.NamedRunnable.run in VM 0 running on Host > a775258ffe87 with 4 VMs > Caused by: > java.lang.IllegalStateException: VM not available: VM 0 running on > Host a775258ffe87 with 4 VMs > org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeDUnitTest > > testRollServersOnReplicatedRegion_dataserializable[2] FAILED > org.apache.geode.test.dunit.RMIException: While invoking > org.apache.geode.test.dunit.NamedRunnable.run in VM 0 running on Host > a775258ffe87 with 4 VMs > Caused by: > java.lang.IllegalStateException: VM not available: VM 0 running on > Host a775258ffe87 with 4 VMs > org.apache.geode.test.dunit.RMIException: While invoking > org.apache.geode.test.dunit.NamedRunnable.run in VM 0 running on Host > a775258ffe87 with 4 VMs > Caused by: > java.lang.IllegalStateException: VM not available: VM 0 running on > Host a775258ffe87 with 4 VMs > {noformat} -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (GEODE-3153) Client receives duplicate events during rolling upgrade
[ https://issues.apache.org/jira/browse/GEODE-3153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/GEODE-3139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/GEODE-3153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/GEODE-3139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/GEODE-3139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/GEODE-3152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Updated] (GEODE-3214) Remove Multistep Commands
[ https://issues.apache.org/jira/browse/GEODE-3214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jared Stewart updated GEODE-3214: - Description: 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. (was: 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.) > 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. > 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] [Created] (GEODE-3217) Reimplement GFSH Query as a single-step command
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
[ 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
[ https://issues.apache.org/jira/browse/GEODE-2920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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.
[ 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] [Created] (GEODE-3216) The new oplog creation adds the current oplog for compation before creating the new oplog.
Anilkumar Gingade created GEODE-3216: Summary: 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 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.
[ 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 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
[ 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
[ 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
[ https://issues.apache.org/jira/browse/GEODE-3212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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 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 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] [Commented] (GEODE-3141) New flow: GetRegion
[ https://issues.apache.org/jira/browse/GEODE-3141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16090079#comment-16090079 ] ASF GitHub Bot commented on GEODE-3141: --- Github user kohlmu-pivotal commented on a diff in the pull request: https://github.com/apache/geode/pull/630#discussion_r127761196 --- 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 -- Updating the documentation of this > 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-3193) locator pid file is removed even if there was a problem while shutting down
[ 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
[ 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 > org.apache.geode.management.internal.ManagementA
[jira] [Resolved] (GEODE-3191) NPE in pulse prevents locator shutdown
[ 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 > org.apache.geode.m
[jira] [Reopened] (GEODE-3191) NPE in pulse prevents locator shutdown
[ 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 > org.apache.geode.management.internal.Managem
[jira] [Resolved] (GEODE-3191) NPE in pulse prevents locator shutdown
[ 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
[ https://issues.apache.org/jira/browse/GEODE-3141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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] [Commented] (GEODE-3212) Spike: How to migrate non persistent region to persistent region without data loss.
[ https://issues.apache.org/jira/browse/GEODE-3212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16090026#comment-16090026 ] Mark Bretl commented on GEODE-3212: --- Hi [~fkrone], How is this ticket related to the Geode community? The scenario for this task makes it seem it is strictly for a commercial product. Although the idea of migrating might be something the community might want to do, it should be discussed on the Dev mailing list. --Mark > 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-2969) Meaningful exception information is stripped during exception handling
[ 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
[ 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
[ https://issues.apache.org/jira/browse/GEODE-3204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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)
[jira] [Created] (GEODE-3212) Spike: How to migrate non persistent region to persistent region without data loss.
Fred Krone created GEODE-3212: - Summary: 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)