[jira] [Updated] (GEODE-3839) log warning when --cache-xml-file is used with cluster config
[
https://issues.apache.org/jira/browse/GEODE-3839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-3839:
--
Labels: pull-request-available (was: )
> log warning when --cache-xml-file is used with cluster config
> -
>
> Key: GEODE-3839
> URL: https://issues.apache.org/jira/browse/GEODE-3839
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Swapnil Bawaskar
>Priority: Major
> Labels: pull-request-available
>
> When a server started using {{gfsh>start server --cache-xml-file=file.xml}}
> the contents of cache.xml are overridden with contents of cluster config. For
> example:
> * When I specify --server-port=0 the default cache server port is used. An
> ephemeral port is never created.
> * Changing a region type from REPLICATE (cluster config) to PARTITION
> (cache.xml) retains the region as REPLICATE.
> * Changing the persistence mode of a region retains the original setting;
> i.e. what is set in cluster config.
> When a user tries to start a server using cache.xml file, we should log a
> warning message saying that cluster xml is going to take precedence over
> contents of cache.xml. We should also change the gfsh help message to reflect
> this.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-5460) SUPERFLAKY: TestFunctionsDUnitTest.testNumOfRunningFunctions
[
https://issues.apache.org/jira/browse/GEODE-5460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Hanson reassigned GEODE-5460:
--
Assignee: Mark Hanson
> SUPERFLAKY: TestFunctionsDUnitTest.testNumOfRunningFunctions
>
>
> Key: GEODE-5460
> URL: https://issues.apache.org/jira/browse/GEODE-5460
> Project: Geode
> Issue Type: Bug
>Reporter: Helena Bales
>Assignee: Mark Hanson
>Priority: Major
> Labels: ci, flaky, swat
>
> {{org.apache.geode.management.internal.pulse.TestFunctionsDUnitTest >
> testNumOfRunningFunctions FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.management.internal.pulse.TestFunctionsDUnitTest$$Lambda$29/242148781.call
> in VM 0 running on Host 57e1ae1f71ab with 4 VMs
> at org.apache.geode.test.dunit.VM.invoke(VM.java:443)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:412)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:378)
> at
> org.apache.geode.management.internal.pulse.TestFunctionsDUnitTest.testNumOfRunningFunctions(TestFunctionsDUnitTest.java:94)
> Caused by:
> java.lang.AssertionError: Event never occurred after 12 ms: wait
> for getNumOfRunningFunction to complete and get results
> at org.junit.Assert.fail(Assert.java:88)
> at
> org.apache.geode.test.dunit.Wait.waitForCriterion(Wait.java:190)
> at
> org.apache.geode.management.internal.pulse.TestFunctionsDUnitTest.getNumOfRunningFunction(TestFunctionsDUnitTest.java:71)
> at
> org.apache.geode.management.internal.pulse.TestFunctionsDUnitTest.lambda$testNumOfRunningFunctions$5c4d653a$1(TestFunctionsDUnitTest.java:94)
> }}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5518) some records in the region are not fetched when executing fetch query
[ https://issues.apache.org/jira/browse/GEODE-5518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16570927#comment-16570927 ] Jason Huynh commented on GEODE-5518: How is the special process getting these records and how is it iterating over the records and deleting them? Shouldn't this discussion be taking place on the user list instead of creating a ticket? There isn't a lot of information for a developer to work on this ticket at the moment... > some records in the region are not fetched when executing fetch query > - > > Key: GEODE-5518 > URL: https://issues.apache.org/jira/browse/GEODE-5518 > Project: Geode > Issue Type: Bug > Components: core, querying >Reporter: yossi reginiano >Priority: Major > > hi all, > we are using geode 1.4 and facing the following: > we are starting to adopt the putAll functions which accepts a bulk of records > and persists them into the region > we have noticed that the process that fetches the records from the region > (executing fetch command with bulks of 1000) , from time to time missing a > record or two , which is causing this records to be left in the region as a > "Zombie" - because now current index is greater then this record's index > now this started to happen only when we started to use the putAll function - > prior to this we did not face any such issue > also - when we are using putAll with only 1 record at a time it is also > working fine > has anybody faced this? > is there some constraint on the number of records that can be sent to the > putAll function? > thanks in advance > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5197) synchronize the adding and removal of cache service profiles while reindexing
[
https://issues.apache.org/jira/browse/GEODE-5197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16570923#comment-16570923
]
ASF subversion and git services commented on GEODE-5197:
Commit 2c139a563b3d8931c26664ed9c54ac202579a438 in geode's branch
refs/heads/develop from [~nabarunnag]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=2c139a5 ]
GEODE-5197: Synchronized update cache service profiles (#2270)
* new lock created for updating the region's cache service profile
* synchronized the addition / validation / removal of
LuceneIndexCreationProfile in the data region.
> synchronize the adding and removal of cache service profiles while reindexing
> -
>
> Key: GEODE-5197
> URL: https://issues.apache.org/jira/browse/GEODE-5197
> Project: Geode
> Issue Type: Sub-task
> Components: lucene
>Reporter: nabarun
>Priority: Major
> Labels: pull-request-available
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> As a gemfire developer, while creating a lucene index on the data region the
> addition/verification/[or removal] to the region's cache service profile
> should not be affected by concurrent index creation.
> The below code needs to be synchronized
> {code:java}
> private void createIndexOnExistingRegion(PartitionedRegion region, String
> indexName,
> String regionPath, String[] fields, Analyzer analyzer, Map Analyzer> fieldAnalyzers,
> LuceneSerializer serializer) {
> validateRegionAttributes(region.getAttributes());
> LuceneIndexCreationProfile luceneIndexCreationProfile = new
> LuceneIndexCreationProfile(
> indexName, regionPath, fields, analyzer, fieldAnalyzers, serializer);
> region.addCacheServiceProfile(luceneIndexCreationProfile);
> try {
> validateLuceneIndexProfile(region);
> } catch (Exception e) {
> region.removeCacheServiceProfile(luceneIndexCreationProfile.getId());
> throw new UnsupportedOperationException(
>
> LocalizedStrings.LuceneIndexCreation_INDEX_CANNOT_BE_CREATED_DUE_TO_PROFILE_VIOLATION
> .toString(indexName),
> e);
> }
> String aeqId = LuceneServiceImpl.getUniqueIndexName(indexName,
> regionPath);
> region.updatePRConfigWithNewGatewaySender(aeqId);
> LuceneIndexImpl luceneIndex = beforeDataRegionCreated(indexName,
> regionPath,
> region.getAttributes(), analyzer, fieldAnalyzers, aeqId, serializer,
> fields);
> afterDataRegionCreated(luceneIndex);
> createLuceneIndexOnDataRegion(region, luceneIndex);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5197) synchronize the adding and removal of cache service profiles while reindexing
[
https://issues.apache.org/jira/browse/GEODE-5197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16570911#comment-16570911
]
ASF subversion and git services commented on GEODE-5197:
Commit 88b379e852b33509b8abd4e7bb82b9a1b62c26b9 in geode's branch
refs/heads/develop from [~nabarunnag]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=88b379e ]
Revert "GEODE-5197: Synchronized update cache service profile in lucene" (#2269)
> synchronize the adding and removal of cache service profiles while reindexing
> -
>
> Key: GEODE-5197
> URL: https://issues.apache.org/jira/browse/GEODE-5197
> Project: Geode
> Issue Type: Sub-task
> Components: lucene
>Reporter: nabarun
>Priority: Major
> Labels: pull-request-available
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> As a gemfire developer, while creating a lucene index on the data region the
> addition/verification/[or removal] to the region's cache service profile
> should not be affected by concurrent index creation.
> The below code needs to be synchronized
> {code:java}
> private void createIndexOnExistingRegion(PartitionedRegion region, String
> indexName,
> String regionPath, String[] fields, Analyzer analyzer, Map Analyzer> fieldAnalyzers,
> LuceneSerializer serializer) {
> validateRegionAttributes(region.getAttributes());
> LuceneIndexCreationProfile luceneIndexCreationProfile = new
> LuceneIndexCreationProfile(
> indexName, regionPath, fields, analyzer, fieldAnalyzers, serializer);
> region.addCacheServiceProfile(luceneIndexCreationProfile);
> try {
> validateLuceneIndexProfile(region);
> } catch (Exception e) {
> region.removeCacheServiceProfile(luceneIndexCreationProfile.getId());
> throw new UnsupportedOperationException(
>
> LocalizedStrings.LuceneIndexCreation_INDEX_CANNOT_BE_CREATED_DUE_TO_PROFILE_VIOLATION
> .toString(indexName),
> e);
> }
> String aeqId = LuceneServiceImpl.getUniqueIndexName(indexName,
> regionPath);
> region.updatePRConfigWithNewGatewaySender(aeqId);
> LuceneIndexImpl luceneIndex = beforeDataRegionCreated(indexName,
> regionPath,
> region.getAttributes(), analyzer, fieldAnalyzers, aeqId, serializer,
> fields);
> afterDataRegionCreated(luceneIndex);
> createLuceneIndexOnDataRegion(region, luceneIndex);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5197) synchronize the adding and removal of cache service profiles while reindexing
[
https://issues.apache.org/jira/browse/GEODE-5197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16570908#comment-16570908
]
ASF subversion and git services commented on GEODE-5197:
Commit 0bad03af681bb611f432009354baf3816e96f101 in geode's branch
refs/heads/develop from nabarun
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=0bad03a ]
GEODE-5197: Synchronized update cache service profile in lucene.
* new lock created for updating the region's cache service profile
* synchronized the addition / validation / removal of
LuceneIndexCreationProfile in the data region.
> synchronize the adding and removal of cache service profiles while reindexing
> -
>
> Key: GEODE-5197
> URL: https://issues.apache.org/jira/browse/GEODE-5197
> Project: Geode
> Issue Type: Sub-task
> Components: lucene
>Reporter: nabarun
>Priority: Major
> Labels: pull-request-available
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> As a gemfire developer, while creating a lucene index on the data region the
> addition/verification/[or removal] to the region's cache service profile
> should not be affected by concurrent index creation.
> The below code needs to be synchronized
> {code:java}
> private void createIndexOnExistingRegion(PartitionedRegion region, String
> indexName,
> String regionPath, String[] fields, Analyzer analyzer, Map Analyzer> fieldAnalyzers,
> LuceneSerializer serializer) {
> validateRegionAttributes(region.getAttributes());
> LuceneIndexCreationProfile luceneIndexCreationProfile = new
> LuceneIndexCreationProfile(
> indexName, regionPath, fields, analyzer, fieldAnalyzers, serializer);
> region.addCacheServiceProfile(luceneIndexCreationProfile);
> try {
> validateLuceneIndexProfile(region);
> } catch (Exception e) {
> region.removeCacheServiceProfile(luceneIndexCreationProfile.getId());
> throw new UnsupportedOperationException(
>
> LocalizedStrings.LuceneIndexCreation_INDEX_CANNOT_BE_CREATED_DUE_TO_PROFILE_VIOLATION
> .toString(indexName),
> e);
> }
> String aeqId = LuceneServiceImpl.getUniqueIndexName(indexName,
> regionPath);
> region.updatePRConfigWithNewGatewaySender(aeqId);
> LuceneIndexImpl luceneIndex = beforeDataRegionCreated(indexName,
> regionPath,
> region.getAttributes(), analyzer, fieldAnalyzers, aeqId, serializer,
> fields);
> afterDataRegionCreated(luceneIndex);
> createLuceneIndexOnDataRegion(region, luceneIndex);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5197) synchronize the adding and removal of cache service profiles while reindexing
[
https://issues.apache.org/jira/browse/GEODE-5197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16570909#comment-16570909
]
ASF subversion and git services commented on GEODE-5197:
Commit 84c1e5f0faf3a3eccc7dafd55dc17434144d599b in geode's branch
refs/heads/develop from [~nabarunnag]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=84c1e5f ]
Merge pull request #1940 from nabarunnag/feature/GEODE-5197
* new lock created for updating the region's cache service profile
* synchronized the addition / validation / removal of
LuceneIndexCreationProfile in the data region.
> synchronize the adding and removal of cache service profiles while reindexing
> -
>
> Key: GEODE-5197
> URL: https://issues.apache.org/jira/browse/GEODE-5197
> Project: Geode
> Issue Type: Sub-task
> Components: lucene
>Reporter: nabarun
>Priority: Major
> Labels: pull-request-available
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> As a gemfire developer, while creating a lucene index on the data region the
> addition/verification/[or removal] to the region's cache service profile
> should not be affected by concurrent index creation.
> The below code needs to be synchronized
> {code:java}
> private void createIndexOnExistingRegion(PartitionedRegion region, String
> indexName,
> String regionPath, String[] fields, Analyzer analyzer, Map Analyzer> fieldAnalyzers,
> LuceneSerializer serializer) {
> validateRegionAttributes(region.getAttributes());
> LuceneIndexCreationProfile luceneIndexCreationProfile = new
> LuceneIndexCreationProfile(
> indexName, regionPath, fields, analyzer, fieldAnalyzers, serializer);
> region.addCacheServiceProfile(luceneIndexCreationProfile);
> try {
> validateLuceneIndexProfile(region);
> } catch (Exception e) {
> region.removeCacheServiceProfile(luceneIndexCreationProfile.getId());
> throw new UnsupportedOperationException(
>
> LocalizedStrings.LuceneIndexCreation_INDEX_CANNOT_BE_CREATED_DUE_TO_PROFILE_VIOLATION
> .toString(indexName),
> e);
> }
> String aeqId = LuceneServiceImpl.getUniqueIndexName(indexName,
> regionPath);
> region.updatePRConfigWithNewGatewaySender(aeqId);
> LuceneIndexImpl luceneIndex = beforeDataRegionCreated(indexName,
> regionPath,
> region.getAttributes(), analyzer, fieldAnalyzers, aeqId, serializer,
> fields);
> afterDataRegionCreated(luceneIndex);
> createLuceneIndexOnDataRegion(region, luceneIndex);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5534) With oql indexes and compression enabled, memory usage is greater after compression than before
[
https://issues.apache.org/jira/browse/GEODE-5534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16570882#comment-16570882
]
Barry Oglesby commented on GEODE-5534:
--
The user needs to validate that compression is actually buying them something.
The CachePerfStats.preCompressedBytes and postCompressedBytes will help with
that validation. If the before and after compression bytes are nearly the same,
then the memory usage will still be greater after compression than before.
Thats because of the string keys in the index.
> With oql indexes and compression enabled, memory usage is greater after
> compression than before
> ---
>
> Key: GEODE-5534
> URL: https://issues.apache.org/jira/browse/GEODE-5534
> Project: Geode
> Issue Type: Bug
> Components: querying
>Reporter: Barry Oglesby
>Assignee: Barry Oglesby
>Priority: Major
> Labels: swat
>
> A test that shows the behavior is:
> - xml configuration like:
> {noformat}
>
> data-policy="persistent-replicate" disk-store-name="orderDiskStore"
> disk-synchronous="false" cloning-enabled="true">
>
> org.apache.geode.compression.SnappyCompressor
>
>
> expression="index_from.clOrdID" type="range"/>
> expression="index_from.externalOrderID" type="range"/>
> expression="index_from.externalOrderIDSource" type="range"/>
> expression="index_from.orderID" type="range"/>
> expression="index_from.parentOrderID" type="range"/>
>
> {noformat}
> - an Order object defining string fields for clOrdID, externalOrderID,
> orderID and parentOrderID and an enum field for externalOrderIDSource
> Here are some histograms showing the behavior:
> With indexes and no compression:
> {noformat}
> num #instances #bytes class name
> --
> 1: 502136 562132008 [B
> 2: 200 4800
> org.apache.geode.internal.concurrent.CompactConcurrentHashSet2$Node
> 3: 40 35999280
> org.apache.geode.internal.cache.entries.VersionedThinDiskRegionEntryHeapStringKey2
> 4: 54 24000192
> org.apache.geode.internal.cache.DiskId$PersistenceWithIntOffset
> 5: 1503 15457776
> [Lorg.apache.geode.internal.concurrent.CompactConcurrentHashSet2$Node;
> 6: 501508 12036192 java.util.concurrent.ConcurrentSkipListMap$Node
> 7: 501500 12036000 org.apache.geode.pdx.internal.PdxString
> 8: 50 800
> org.apache.geode.internal.cache.PreferBytesCachedDeserializable
> 9: 250680 6016320 java.util.concurrent.ConcurrentSkipListMap$Index
> 10: 80 4196104
> [Lorg.apache.geode.internal.util.concurrent.CustomEntryConcurrentHashMap$HashEntry;
> Total 5474612 739440976
> {noformat}
> With indexes and compression
> {noformat}
> num #instances #bytes class name
> --
> 1: 1003644 643754184 [B
> 2: 200 4800
> org.apache.geode.internal.concurrent.CompactConcurrentHashSet2$Node
> 3: 40 35999280
> org.apache.geode.internal.cache.entries.VersionedThinDiskRegionEntryHeapStringKey2
> 4: 54 24000192
> org.apache.geode.internal.cache.DiskId$PersistenceWithIntOffset
> 5: 1503 15457776
> [Lorg.apache.geode.internal.concurrent.CompactConcurrentHashSet2$Node;
> 6: 501508 12036192 java.util.concurrent.ConcurrentSkipListMap$Node
> 7: 501500 12036000 org.apache.geode.pdx.internal.PdxString
> 8: 250889 6021336 java.util.concurrent.ConcurrentSkipListMap$Index
> 9: 80 4196096
> [Lorg.apache.geode.internal.util.concurrent.CustomEntryConcurrentHashMap$HashEntry;
> 10: 34380 3261936 [C
> Total 5476808 813096488
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5533) ./gradlew install fails with "Could not publish configuration 'archives'"
[
https://issues.apache.org/jira/browse/GEODE-5533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16570873#comment-16570873
]
ASF subversion and git services commented on GEODE-5533:
Commit 3f51242334260c1e13f56690b3b698a707ee0130 in geode's branch
refs/heads/develop from [~rhoughton]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=3f51242 ]
GEODE-5533 Support Gradle 4.9 publication enhancements (#2264)
* GEODE-5533 Support Gradle 4.9 publication enhancements
Upgrading to Gradle 4.9 broke publish/install due to a non-existent jar
output from geode-assembly. More diligent pruning of the archives
configuration has fixed the problem.
* include `install` task in Concourse build
Co-authored-by: Patrick Rhomberg
> ./gradlew install fails with "Could not publish configuration 'archives'"
> -
>
> Key: GEODE-5533
> URL: https://issues.apache.org/jira/browse/GEODE-5533
> Project: Geode
> Issue Type: Task
> Components: build
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>Priority: Major
> Labels: pull-request-available
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> Some targets changed in gradle 4.8 -> 4.9. The configuration step of
> removing jar inclusion to the publication or the archives was invalidated.
> This step needs to be updated to conform to the new targets.
> {noformat}
> > Task :geode-assembly:install FAILED
> FAILURE: Build failed with an exception.
> * What went wrong:
> Execution failed for task ':geode-assembly:install'.
> > Could not publish configuration 'archives'
>> Cannot publish artifact 'geode-assembly.jar'
> (/Users/prhomberg/workspace/gemfire/open/geode-assembly/build/libs/geode-assembly-1.8.0-SNAPSHOT.jar)
> as it does not exist.
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5533) ./gradlew install fails with "Could not publish configuration 'archives'"
[
https://issues.apache.org/jira/browse/GEODE-5533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16570872#comment-16570872
]
ASF subversion and git services commented on GEODE-5533:
Commit 3f51242334260c1e13f56690b3b698a707ee0130 in geode's branch
refs/heads/develop from [~rhoughton]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=3f51242 ]
GEODE-5533 Support Gradle 4.9 publication enhancements (#2264)
* GEODE-5533 Support Gradle 4.9 publication enhancements
Upgrading to Gradle 4.9 broke publish/install due to a non-existent jar
output from geode-assembly. More diligent pruning of the archives
configuration has fixed the problem.
* include `install` task in Concourse build
Co-authored-by: Patrick Rhomberg
> ./gradlew install fails with "Could not publish configuration 'archives'"
> -
>
> Key: GEODE-5533
> URL: https://issues.apache.org/jira/browse/GEODE-5533
> Project: Geode
> Issue Type: Task
> Components: build
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>Priority: Major
> Labels: pull-request-available
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> Some targets changed in gradle 4.8 -> 4.9. The configuration step of
> removing jar inclusion to the publication or the archives was invalidated.
> This step needs to be updated to conform to the new targets.
> {noformat}
> > Task :geode-assembly:install FAILED
> FAILURE: Build failed with an exception.
> * What went wrong:
> Execution failed for task ':geode-assembly:install'.
> > Could not publish configuration 'archives'
>> Cannot publish artifact 'geode-assembly.jar'
> (/Users/prhomberg/workspace/gemfire/open/geode-assembly/build/libs/geode-assembly-1.8.0-SNAPSHOT.jar)
> as it does not exist.
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5534) With oql indexes and compression enabled, memory usage is greater after compression than before
[
https://issues.apache.org/jira/browse/GEODE-5534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16570858#comment-16570858
]
Barry Oglesby commented on GEODE-5534:
--
The PdxStrings are referencing decompressed byte[]s. In the case of PDX values
and compressed region entries, PdxStrings should not be used. Instead, Strings
should be used.
With indexes and compression and changes to use String key in case of
compression:
{noformat}
num #instances #bytes class name
--
1: 502136 80427400 [B
2: 200 4800
org.apache.geode.internal.concurrent.CompactConcurrentHashSet2$Node
3: 40 35999280
org.apache.geode.internal.cache.entries.VersionedThinDiskRegionEntryHeapStringKey2
4: 54 24000192
org.apache.geode.internal.cache.DiskId$PersistenceWithIntOffset
5: 535915 23319712 [C
6: 1503 15457776
[Lorg.apache.geode.internal.concurrent.CompactConcurrentHashSet2$Node;
7: 535644 12855456 java.lang.String
8: 501508 12036192 java.util.concurrent.ConcurrentSkipListMap$Node
9: 251648 6039552 java.util.concurrent.ConcurrentSkipListMap$Index
10: 80 4196096
[Lorg.apache.geode.internal.util.concurrent.CustomEntryConcurrentHashMap$HashEntry;
Total 5477564 269878296
{noformat}
> With oql indexes and compression enabled, memory usage is greater after
> compression than before
> ---
>
> Key: GEODE-5534
> URL: https://issues.apache.org/jira/browse/GEODE-5534
> Project: Geode
> Issue Type: Bug
> Components: querying
>Reporter: Barry Oglesby
>Assignee: Barry Oglesby
>Priority: Major
> Labels: swat
>
> A test that shows the behavior is:
> - xml configuration like:
> {noformat}
>
> data-policy="persistent-replicate" disk-store-name="orderDiskStore"
> disk-synchronous="false" cloning-enabled="true">
>
> org.apache.geode.compression.SnappyCompressor
>
>
> expression="index_from.clOrdID" type="range"/>
> expression="index_from.externalOrderID" type="range"/>
> expression="index_from.externalOrderIDSource" type="range"/>
> expression="index_from.orderID" type="range"/>
> expression="index_from.parentOrderID" type="range"/>
>
> {noformat}
> - an Order object defining string fields for clOrdID, externalOrderID,
> orderID and parentOrderID and an enum field for externalOrderIDSource
> Here are some histograms showing the behavior:
> With indexes and no compression:
> {noformat}
> num #instances #bytes class name
> --
> 1: 502136 562132008 [B
> 2: 200 4800
> org.apache.geode.internal.concurrent.CompactConcurrentHashSet2$Node
> 3: 40 35999280
> org.apache.geode.internal.cache.entries.VersionedThinDiskRegionEntryHeapStringKey2
> 4: 54 24000192
> org.apache.geode.internal.cache.DiskId$PersistenceWithIntOffset
> 5: 1503 15457776
> [Lorg.apache.geode.internal.concurrent.CompactConcurrentHashSet2$Node;
> 6: 501508 12036192 java.util.concurrent.ConcurrentSkipListMap$Node
> 7: 501500 12036000 org.apache.geode.pdx.internal.PdxString
> 8: 50 800
> org.apache.geode.internal.cache.PreferBytesCachedDeserializable
> 9: 250680 6016320 java.util.concurrent.ConcurrentSkipListMap$Index
> 10: 80 4196104
> [Lorg.apache.geode.internal.util.concurrent.CustomEntryConcurrentHashMap$HashEntry;
> Total 5474612 739440976
> {noformat}
> With indexes and compression
> {noformat}
> num #instances #bytes class name
> --
> 1: 1003644 643754184 [B
> 2: 200 4800
> org.apache.geode.internal.concurrent.CompactConcurrentHashSet2$Node
> 3: 40 35999280
> org.apache.geode.internal.cache.entries.VersionedThinDiskRegionEntryHeapStringKey2
> 4: 54 24000192
> org.apache.geode.internal.cache.DiskId$PersistenceWithIntOffset
> 5: 1503 15457776
> [Lorg.apache.geode.internal.concurrent.CompactConcurrentHashSet2$Node;
> 6: 501508 12036192 java.util.concurrent.ConcurrentSkipListMap$Node
> 7: 501500 12036000 org.apache.geode.pdx.internal.PdxString
> 8: 250889 6021336 java.util.concurrent.ConcurrentSkipListMap$Index
> 9: 80 4196096
> [Lorg.apache.geode.internal.util.concurrent.CustomEntryConcurrentHashMap$HashEntry;
> 10: 34380 3261936 [C
> Total 5476808 813096488
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-5534) With oql indexes and compression enabled, memory usage is greater after compression than before
[
https://issues.apache.org/jira/browse/GEODE-5534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barry Oglesby reassigned GEODE-5534:
Assignee: Barry Oglesby
> With oql indexes and compression enabled, memory usage is greater after
> compression than before
> ---
>
> Key: GEODE-5534
> URL: https://issues.apache.org/jira/browse/GEODE-5534
> Project: Geode
> Issue Type: Bug
> Components: querying
>Reporter: Barry Oglesby
>Assignee: Barry Oglesby
>Priority: Major
> Labels: swat
>
> A test that shows the behavior is:
> - xml configuration like:
> {noformat}
>
> data-policy="persistent-replicate" disk-store-name="orderDiskStore"
> disk-synchronous="false" cloning-enabled="true">
>
> org.apache.geode.compression.SnappyCompressor
>
>
> expression="index_from.clOrdID" type="range"/>
> expression="index_from.externalOrderID" type="range"/>
> expression="index_from.externalOrderIDSource" type="range"/>
> expression="index_from.orderID" type="range"/>
> expression="index_from.parentOrderID" type="range"/>
>
> {noformat}
> - an Order object defining string fields for clOrdID, externalOrderID,
> orderID and parentOrderID and an enum field for externalOrderIDSource
> Here are some histograms showing the behavior:
> With indexes and no compression:
> {noformat}
> num #instances #bytes class name
> --
> 1: 502136 562132008 [B
> 2: 200 4800
> org.apache.geode.internal.concurrent.CompactConcurrentHashSet2$Node
> 3: 40 35999280
> org.apache.geode.internal.cache.entries.VersionedThinDiskRegionEntryHeapStringKey2
> 4: 54 24000192
> org.apache.geode.internal.cache.DiskId$PersistenceWithIntOffset
> 5: 1503 15457776
> [Lorg.apache.geode.internal.concurrent.CompactConcurrentHashSet2$Node;
> 6: 501508 12036192 java.util.concurrent.ConcurrentSkipListMap$Node
> 7: 501500 12036000 org.apache.geode.pdx.internal.PdxString
> 8: 50 800
> org.apache.geode.internal.cache.PreferBytesCachedDeserializable
> 9: 250680 6016320 java.util.concurrent.ConcurrentSkipListMap$Index
> 10: 80 4196104
> [Lorg.apache.geode.internal.util.concurrent.CustomEntryConcurrentHashMap$HashEntry;
> Total 5474612 739440976
> {noformat}
> With indexes and compression
> {noformat}
> num #instances #bytes class name
> --
> 1: 1003644 643754184 [B
> 2: 200 4800
> org.apache.geode.internal.concurrent.CompactConcurrentHashSet2$Node
> 3: 40 35999280
> org.apache.geode.internal.cache.entries.VersionedThinDiskRegionEntryHeapStringKey2
> 4: 54 24000192
> org.apache.geode.internal.cache.DiskId$PersistenceWithIntOffset
> 5: 1503 15457776
> [Lorg.apache.geode.internal.concurrent.CompactConcurrentHashSet2$Node;
> 6: 501508 12036192 java.util.concurrent.ConcurrentSkipListMap$Node
> 7: 501500 12036000 org.apache.geode.pdx.internal.PdxString
> 8: 250889 6021336 java.util.concurrent.ConcurrentSkipListMap$Index
> 9: 80 4196096
> [Lorg.apache.geode.internal.util.concurrent.CustomEntryConcurrentHashMap$HashEntry;
> 10: 34380 3261936 [C
> Total 5476808 813096488
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5534) With oql indexes and compression enabled, memory usage is greater after compression than before
[
https://issues.apache.org/jira/browse/GEODE-5534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barry Oglesby updated GEODE-5534:
-
Labels: swat (was: )
> With oql indexes and compression enabled, memory usage is greater after
> compression than before
> ---
>
> Key: GEODE-5534
> URL: https://issues.apache.org/jira/browse/GEODE-5534
> Project: Geode
> Issue Type: Bug
> Components: querying
>Reporter: Barry Oglesby
>Assignee: Barry Oglesby
>Priority: Major
> Labels: swat
>
> A test that shows the behavior is:
> - xml configuration like:
> {noformat}
>
> data-policy="persistent-replicate" disk-store-name="orderDiskStore"
> disk-synchronous="false" cloning-enabled="true">
>
> org.apache.geode.compression.SnappyCompressor
>
>
> expression="index_from.clOrdID" type="range"/>
> expression="index_from.externalOrderID" type="range"/>
> expression="index_from.externalOrderIDSource" type="range"/>
> expression="index_from.orderID" type="range"/>
> expression="index_from.parentOrderID" type="range"/>
>
> {noformat}
> - an Order object defining string fields for clOrdID, externalOrderID,
> orderID and parentOrderID and an enum field for externalOrderIDSource
> Here are some histograms showing the behavior:
> With indexes and no compression:
> {noformat}
> num #instances #bytes class name
> --
> 1: 502136 562132008 [B
> 2: 200 4800
> org.apache.geode.internal.concurrent.CompactConcurrentHashSet2$Node
> 3: 40 35999280
> org.apache.geode.internal.cache.entries.VersionedThinDiskRegionEntryHeapStringKey2
> 4: 54 24000192
> org.apache.geode.internal.cache.DiskId$PersistenceWithIntOffset
> 5: 1503 15457776
> [Lorg.apache.geode.internal.concurrent.CompactConcurrentHashSet2$Node;
> 6: 501508 12036192 java.util.concurrent.ConcurrentSkipListMap$Node
> 7: 501500 12036000 org.apache.geode.pdx.internal.PdxString
> 8: 50 800
> org.apache.geode.internal.cache.PreferBytesCachedDeserializable
> 9: 250680 6016320 java.util.concurrent.ConcurrentSkipListMap$Index
> 10: 80 4196104
> [Lorg.apache.geode.internal.util.concurrent.CustomEntryConcurrentHashMap$HashEntry;
> Total 5474612 739440976
> {noformat}
> With indexes and compression
> {noformat}
> num #instances #bytes class name
> --
> 1: 1003644 643754184 [B
> 2: 200 4800
> org.apache.geode.internal.concurrent.CompactConcurrentHashSet2$Node
> 3: 40 35999280
> org.apache.geode.internal.cache.entries.VersionedThinDiskRegionEntryHeapStringKey2
> 4: 54 24000192
> org.apache.geode.internal.cache.DiskId$PersistenceWithIntOffset
> 5: 1503 15457776
> [Lorg.apache.geode.internal.concurrent.CompactConcurrentHashSet2$Node;
> 6: 501508 12036192 java.util.concurrent.ConcurrentSkipListMap$Node
> 7: 501500 12036000 org.apache.geode.pdx.internal.PdxString
> 8: 250889 6021336 java.util.concurrent.ConcurrentSkipListMap$Index
> 9: 80 4196096
> [Lorg.apache.geode.internal.util.concurrent.CustomEntryConcurrentHashMap$HashEntry;
> 10: 34380 3261936 [C
> Total 5476808 813096488
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-5534) With oql indexes and compression enabled, memory usage is greater after compression than before
Barry Oglesby created GEODE-5534:
Summary: With oql indexes and compression enabled, memory usage is
greater after compression than before
Key: GEODE-5534
URL: https://issues.apache.org/jira/browse/GEODE-5534
Project: Geode
Issue Type: Bug
Components: querying
Reporter: Barry Oglesby
A test that shows the behavior is:
- xml configuration like:
{noformat}
org.apache.geode.compression.SnappyCompressor
{noformat}
- an Order object defining string fields for clOrdID, externalOrderID, orderID
and parentOrderID and an enum field for externalOrderIDSource
Here are some histograms showing the behavior:
With indexes and no compression:
{noformat}
num #instances #bytes class name
--
1: 502136 562132008 [B
2: 200 4800
org.apache.geode.internal.concurrent.CompactConcurrentHashSet2$Node
3: 40 35999280
org.apache.geode.internal.cache.entries.VersionedThinDiskRegionEntryHeapStringKey2
4: 54 24000192
org.apache.geode.internal.cache.DiskId$PersistenceWithIntOffset
5: 1503 15457776
[Lorg.apache.geode.internal.concurrent.CompactConcurrentHashSet2$Node;
6: 501508 12036192 java.util.concurrent.ConcurrentSkipListMap$Node
7: 501500 12036000 org.apache.geode.pdx.internal.PdxString
8: 50 800
org.apache.geode.internal.cache.PreferBytesCachedDeserializable
9: 250680 6016320 java.util.concurrent.ConcurrentSkipListMap$Index
10: 80 4196104
[Lorg.apache.geode.internal.util.concurrent.CustomEntryConcurrentHashMap$HashEntry;
Total 5474612 739440976
{noformat}
With indexes and compression
{noformat}
num #instances #bytes class name
--
1: 1003644 643754184 [B
2: 200 4800
org.apache.geode.internal.concurrent.CompactConcurrentHashSet2$Node
3: 40 35999280
org.apache.geode.internal.cache.entries.VersionedThinDiskRegionEntryHeapStringKey2
4: 54 24000192
org.apache.geode.internal.cache.DiskId$PersistenceWithIntOffset
5: 1503 15457776
[Lorg.apache.geode.internal.concurrent.CompactConcurrentHashSet2$Node;
6: 501508 12036192 java.util.concurrent.ConcurrentSkipListMap$Node
7: 501500 12036000 org.apache.geode.pdx.internal.PdxString
8: 250889 6021336 java.util.concurrent.ConcurrentSkipListMap$Index
9: 80 4196096
[Lorg.apache.geode.internal.util.concurrent.CustomEntryConcurrentHashMap$HashEntry;
10: 34380 3261936 [C
Total 5476808 813096488
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-577) SUPERFLAKY: QueryMonitorDUnitTest is flaky and needs to be rewritten (60 failures in 200)
[
https://issues.apache.org/jira/browse/GEODE-577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16570794#comment-16570794
]
ASF subversion and git services commented on GEODE-577:
---
Commit 002efecdb188b24977374f12cbac3aaab955e81c in geode's branch
refs/heads/develop from [~jinmeiliao]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=002efec ]
Revert "GEODE-577: rewrite QueryMonitorDUnitTest (#2179)"
This reverts commit 38e1714
> SUPERFLAKY: QueryMonitorDUnitTest is flaky and needs to be rewritten (60
> failures in 200)
> -
>
> Key: GEODE-577
> URL: https://issues.apache.org/jira/browse/GEODE-577
> Project: Geode
> Issue Type: Bug
> Components: querying
>Reporter: Barry Oglesby
>Assignee: Jinmei Liao
>Priority: Major
> Labels: CI, Flaky, pull-request-available, swat
> Fix For: 1.7.0
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> GemFire_develop_DistributedTests
> Private Build #38 (Nov 15, 2015 3:12:12 PM)
> Revision: b7f640cf2e41acb40a531cc7abbee932a9ea093c
> Revision: 88da702593157d8a0c014295cab16149fc088dfc
> Error Message
> {noformat}
> dunit.RMIException: While invoking
> com.gemstone.gemfire.cache.query.dunit.QueryMonitorDUnitTest$14.run in VM 1
> running on Host latvia.gemstone.com with 4 VMs
> {noformat}
> Stacktrace
> {noformat}
> dunit.RMIException: While invoking
> com.gemstone.gemfire.cache.query.dunit.QueryMonitorDUnitTest$14.run in VM 1
> running on Host latvia.gemstone.com with 4 VMs
> at dunit.VM.invoke(VM.java:369)
> at dunit.VM.invoke(VM.java:312)
> at dunit.VM.invoke(VM.java:266)
> at
> com.gemstone.gemfire.cache.query.dunit.QueryMonitorDUnitTest.testQueryExecutionLocally(QueryMonitorDUnitTest.java:493)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at junit.framework.TestCase.runBare(TestCase.java:141)
> at junit.framework.TestResult$1.protect(TestResult.java:122)
> at junit.framework.TestResult.runProtected(TestResult.java:142)
> at junit.framework.TestResult.run(TestResult.java:125)
> at junit.framework.TestCase.run(TestCase.java:129)
> at junit.framework.TestSuite.runTest(TestSuite.java:252)
> at junit.framework.TestSuite.run(TestSuite.java:247)
> at
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:86)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:105)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:56)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:64)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:50)
> at sun.reflect.GeneratedMethodAccessor124.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> at
> org.gradle.messaging.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
> at
> org.gradle.messaging.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
> at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
> at
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:106)
> at sun.reflect.GeneratedMethodAccessor123.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> at
> org.gradle.messaging.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:360)
> at
> org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:54)
> at
>
[jira] [Updated] (GEODE-5257) ComparisonFailure in ShorteningExpirationTimeRegressionTest.customEntryTimeToLiveCanBeShortened
[
https://issues.apache.org/jira/browse/GEODE-5257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-5257:
--
Labels: pull-request-available swat (was: swat)
> ComparisonFailure in
> ShorteningExpirationTimeRegressionTest.customEntryTimeToLiveCanBeShortened
> ---
>
> Key: GEODE-5257
> URL: https://issues.apache.org/jira/browse/GEODE-5257
> Project: Geode
> Issue Type: Bug
> Components: regions
>Reporter: Dale Emery
>Assignee: Jinmei Liao
>Priority: Major
> Labels: pull-request-available, swat
>
> [http://precheckin.gemfire.pivotal.io/teams/main/pipelines/dale-pr-1994/jobs/integrationTest/builds/1]
> The PR that invoked this precheckin changed a single line in the Spotless
> configuration. It is extremely unlikely that the failure is related to that
> change.
> {noformat}
> org.apache.geode.cache30.ShorteningExpirationTimeRegressionTest >
> customEntryTimeToLiveCanBeShortened FAILED
> org.junit.ComparisonFailure: expected:<"quickExpire"> but was:
> 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.cache30.ShorteningExpirationTimeRegressionTest.customEntryTimeToLiveCanBeShortened(ShorteningExpirationTimeRegressionTest.java:103)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5533) ./gradlew install fails with "Could not publish configuration 'archives'"
[
https://issues.apache.org/jira/browse/GEODE-5533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg updated GEODE-5533:
Summary: ./gradlew install fails with "Could not publish configuration
'archives'" (was: ./gradlew install fails during "Could not publish
configuration 'archives'")
> ./gradlew install fails with "Could not publish configuration 'archives'"
> -
>
> Key: GEODE-5533
> URL: https://issues.apache.org/jira/browse/GEODE-5533
> Project: Geode
> Issue Type: Task
> Components: build
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>Priority: Major
> Labels: pull-request-available
>
> Some targets changed in gradle 4.8 -> 4.9. The configuration step of
> removing jar inclusion to the publication or the archives was invalidated.
> This step needs to be updated to conform to the new targets.
> {noformat}
> > Task :geode-assembly:install FAILED
> FAILURE: Build failed with an exception.
> * What went wrong:
> Execution failed for task ':geode-assembly:install'.
> > Could not publish configuration 'archives'
>> Cannot publish artifact 'geode-assembly.jar'
> (/Users/prhomberg/workspace/gemfire/open/geode-assembly/build/libs/geode-assembly-1.8.0-SNAPSHOT.jar)
> as it does not exist.
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-5533) ./gradlew install fails during "Could not publish configuration 'archives'"
[
https://issues.apache.org/jira/browse/GEODE-5533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg reassigned GEODE-5533:
---
Assignee: Patrick Rhomberg
> ./gradlew install fails during "Could not publish configuration 'archives'"
> ---
>
> Key: GEODE-5533
> URL: https://issues.apache.org/jira/browse/GEODE-5533
> Project: Geode
> Issue Type: Task
> Components: build
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>Priority: Major
> Labels: pull-request-available
>
> Some targets changed in gradle 4.8 -> 4.9. The configuration step of
> removing jar inclusion to the publication or the archives was invalidated.
> This step needs to be updated to conform to the new targets.
> {noformat}
> > Task :geode-assembly:install FAILED
> FAILURE: Build failed with an exception.
> * What went wrong:
> Execution failed for task ':geode-assembly:install'.
> > Could not publish configuration 'archives'
>> Cannot publish artifact 'geode-assembly.jar'
> (/Users/prhomberg/workspace/gemfire/open/geode-assembly/build/libs/geode-assembly-1.8.0-SNAPSHOT.jar)
> as it does not exist.
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5533) ./gradlew install fails during "Could not publish configuration 'archives'"
[
https://issues.apache.org/jira/browse/GEODE-5533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg updated GEODE-5533:
Component/s: build
> ./gradlew install fails during "Could not publish configuration 'archives'"
> ---
>
> Key: GEODE-5533
> URL: https://issues.apache.org/jira/browse/GEODE-5533
> Project: Geode
> Issue Type: Task
> Components: build
>Reporter: Patrick Rhomberg
>Priority: Major
> Labels: pull-request-available
>
> Some targets changed in gradle 4.8 -> 4.9. The configuration step of
> removing jar inclusion to the publication or the archives was invalidated.
> This step needs to be updated to conform to the new targets.
> {noformat}
> > Task :geode-assembly:install FAILED
> FAILURE: Build failed with an exception.
> * What went wrong:
> Execution failed for task ':geode-assembly:install'.
> > Could not publish configuration 'archives'
>> Cannot publish artifact 'geode-assembly.jar'
> (/Users/prhomberg/workspace/gemfire/open/geode-assembly/build/libs/geode-assembly-1.8.0-SNAPSHOT.jar)
> as it does not exist.
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-5533) ./gradlew install fails during "Could not publish configuration 'archives'"
Patrick Rhomberg created GEODE-5533:
---
Summary: ./gradlew install fails during "Could not publish
configuration 'archives'"
Key: GEODE-5533
URL: https://issues.apache.org/jira/browse/GEODE-5533
Project: Geode
Issue Type: Task
Reporter: Patrick Rhomberg
Some targets changed in gradle 4.8 -> 4.9. The configuration step of removing
jar inclusion to the publication or the archives was invalidated. This step
needs to be updated to conform to the new targets.
{noformat}
> Task :geode-assembly:install FAILED
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':geode-assembly:install'.
> Could not publish configuration 'archives'
> Cannot publish artifact 'geode-assembly.jar'
(/Users/prhomberg/workspace/gemfire/open/geode-assembly/build/libs/geode-assembly-1.8.0-SNAPSHOT.jar)
as it does not exist.
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5502) Cluster configuration can contain member-specific gateway receiver definitions which cause members to fail to start during rolling
[
https://issues.apache.org/jira/browse/GEODE-5502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16570764#comment-16570764
]
ASF subversion and git services commented on GEODE-5502:
Commit 2ae2b591378a2cae8f5dee8f01bc07de8cce6d6e in geode's branch
refs/heads/develop from [~barry.oglesby]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=2ae2b59 ]
GEODE-5502: Removed duplicate / member-specific receivers from cluster
configuration
> Cluster configuration can contain member-specific gateway receiver
> definitions which cause members to fail to start during rolling
> --
>
> Key: GEODE-5502
> URL: https://issues.apache.org/jira/browse/GEODE-5502
> Project: Geode
> Issue Type: Bug
> Components: configuration
>Reporter: Barry Oglesby
>Assignee: Barry Oglesby
>Priority: Major
> Labels: pull-request-available, swat
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> In versions before 1.4.0, cluster configuration could contain multiple
> member-specific gateway receiver definitions like:
> {noformat}
>
>
>
>
> {noformat}
> Starting in 1.4.0, multiple receivers are no longer allowed, so a
> configuration like this causes the member to throw an exception and fail to
> start.
> These member-specific receivers should be removed before sending the cluster
> configuration to new members to avoid attempting to create multiple receivers
> in a single member.
> Note: In this case, the member will start with no receivers.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-5257) ComparisonFailure in ShorteningExpirationTimeRegressionTest.customEntryTimeToLiveCanBeShortened
[
https://issues.apache.org/jira/browse/GEODE-5257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao reassigned GEODE-5257:
--
Assignee: Jinmei Liao
> ComparisonFailure in
> ShorteningExpirationTimeRegressionTest.customEntryTimeToLiveCanBeShortened
> ---
>
> Key: GEODE-5257
> URL: https://issues.apache.org/jira/browse/GEODE-5257
> Project: Geode
> Issue Type: Bug
> Components: regions
>Reporter: Dale Emery
>Assignee: Jinmei Liao
>Priority: Major
> Labels: swat
>
> [http://precheckin.gemfire.pivotal.io/teams/main/pipelines/dale-pr-1994/jobs/integrationTest/builds/1]
> The PR that invoked this precheckin changed a single line in the Spotless
> configuration. It is extremely unlikely that the failure is related to that
> change.
> {noformat}
> org.apache.geode.cache30.ShorteningExpirationTimeRegressionTest >
> customEntryTimeToLiveCanBeShortened FAILED
> org.junit.ComparisonFailure: expected:<"quickExpire"> but was:
> 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.cache30.ShorteningExpirationTimeRegressionTest.customEntryTimeToLiveCanBeShortened(ShorteningExpirationTimeRegressionTest.java:103)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-577) SUPERFLAKY: QueryMonitorDUnitTest is flaky and needs to be rewritten (60 failures in 200)
[
https://issues.apache.org/jira/browse/GEODE-577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao resolved GEODE-577.
---
Resolution: Fixed
> SUPERFLAKY: QueryMonitorDUnitTest is flaky and needs to be rewritten (60
> failures in 200)
> -
>
> Key: GEODE-577
> URL: https://issues.apache.org/jira/browse/GEODE-577
> Project: Geode
> Issue Type: Bug
> Components: querying
>Reporter: Barry Oglesby
>Assignee: Jinmei Liao
>Priority: Major
> Labels: CI, Flaky, pull-request-available, swat
> Fix For: 1.7.0
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> GemFire_develop_DistributedTests
> Private Build #38 (Nov 15, 2015 3:12:12 PM)
> Revision: b7f640cf2e41acb40a531cc7abbee932a9ea093c
> Revision: 88da702593157d8a0c014295cab16149fc088dfc
> Error Message
> {noformat}
> dunit.RMIException: While invoking
> com.gemstone.gemfire.cache.query.dunit.QueryMonitorDUnitTest$14.run in VM 1
> running on Host latvia.gemstone.com with 4 VMs
> {noformat}
> Stacktrace
> {noformat}
> dunit.RMIException: While invoking
> com.gemstone.gemfire.cache.query.dunit.QueryMonitorDUnitTest$14.run in VM 1
> running on Host latvia.gemstone.com with 4 VMs
> at dunit.VM.invoke(VM.java:369)
> at dunit.VM.invoke(VM.java:312)
> at dunit.VM.invoke(VM.java:266)
> at
> com.gemstone.gemfire.cache.query.dunit.QueryMonitorDUnitTest.testQueryExecutionLocally(QueryMonitorDUnitTest.java:493)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at junit.framework.TestCase.runBare(TestCase.java:141)
> at junit.framework.TestResult$1.protect(TestResult.java:122)
> at junit.framework.TestResult.runProtected(TestResult.java:142)
> at junit.framework.TestResult.run(TestResult.java:125)
> at junit.framework.TestCase.run(TestCase.java:129)
> at junit.framework.TestSuite.runTest(TestSuite.java:252)
> at junit.framework.TestSuite.run(TestSuite.java:247)
> at
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:86)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:105)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:56)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:64)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:50)
> at sun.reflect.GeneratedMethodAccessor124.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> at
> org.gradle.messaging.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
> at
> org.gradle.messaging.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
> at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
> at
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:106)
> at sun.reflect.GeneratedMethodAccessor123.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> at
> org.gradle.messaging.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:360)
> at
> org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:54)
> at
> org.gradle.internal.concurrent.StoppableExecutorImpl$1.run(StoppableExecutorImpl.java:40)
> 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:745)
> Caused by:
[jira] [Commented] (GEODE-577) SUPERFLAKY: QueryMonitorDUnitTest is flaky and needs to be rewritten (60 failures in 200)
[
https://issues.apache.org/jira/browse/GEODE-577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16570739#comment-16570739
]
ASF subversion and git services commented on GEODE-577:
---
Commit 38e1714b54894caafa508dab9634d62a9c4c42fc in geode's branch
refs/heads/develop from jinmeiliao
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=38e1714 ]
GEODE-577: rewrite QueryMonitorDUnitTest (#2179)
* code cleanup.
* add QueryMonitor unit test
* do not add cq query to the monitor queue
> SUPERFLAKY: QueryMonitorDUnitTest is flaky and needs to be rewritten (60
> failures in 200)
> -
>
> Key: GEODE-577
> URL: https://issues.apache.org/jira/browse/GEODE-577
> Project: Geode
> Issue Type: Bug
> Components: querying
>Reporter: Barry Oglesby
>Assignee: Jinmei Liao
>Priority: Major
> Labels: CI, Flaky, pull-request-available, swat
> Fix For: 1.7.0
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> GemFire_develop_DistributedTests
> Private Build #38 (Nov 15, 2015 3:12:12 PM)
> Revision: b7f640cf2e41acb40a531cc7abbee932a9ea093c
> Revision: 88da702593157d8a0c014295cab16149fc088dfc
> Error Message
> {noformat}
> dunit.RMIException: While invoking
> com.gemstone.gemfire.cache.query.dunit.QueryMonitorDUnitTest$14.run in VM 1
> running on Host latvia.gemstone.com with 4 VMs
> {noformat}
> Stacktrace
> {noformat}
> dunit.RMIException: While invoking
> com.gemstone.gemfire.cache.query.dunit.QueryMonitorDUnitTest$14.run in VM 1
> running on Host latvia.gemstone.com with 4 VMs
> at dunit.VM.invoke(VM.java:369)
> at dunit.VM.invoke(VM.java:312)
> at dunit.VM.invoke(VM.java:266)
> at
> com.gemstone.gemfire.cache.query.dunit.QueryMonitorDUnitTest.testQueryExecutionLocally(QueryMonitorDUnitTest.java:493)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at junit.framework.TestCase.runBare(TestCase.java:141)
> at junit.framework.TestResult$1.protect(TestResult.java:122)
> at junit.framework.TestResult.runProtected(TestResult.java:142)
> at junit.framework.TestResult.run(TestResult.java:125)
> at junit.framework.TestCase.run(TestCase.java:129)
> at junit.framework.TestSuite.runTest(TestSuite.java:252)
> at junit.framework.TestSuite.run(TestSuite.java:247)
> at
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:86)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:105)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:56)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:64)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:50)
> at sun.reflect.GeneratedMethodAccessor124.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> at
> org.gradle.messaging.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
> at
> org.gradle.messaging.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
> at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
> at
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:106)
> at sun.reflect.GeneratedMethodAccessor123.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> at
> org.gradle.messaging.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:360)
> at
> org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:54)
>
[jira] [Resolved] (GEODE-5529) Remove SchedulingOrder
[ https://issues.apache.org/jira/browse/GEODE-5529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Galen O'Sullivan resolved GEODE-5529. - Resolution: Fixed Fix Version/s: 1.7.0 > Remove SchedulingOrder > -- > > Key: GEODE-5529 > URL: https://issues.apache.org/jira/browse/GEODE-5529 > Project: Geode > Issue Type: Task > Components: tests >Reporter: Galen O'Sullivan >Assignee: Galen O'Sullivan >Priority: Major > Labels: pull-request-available > Fix For: 1.7.0 > > Time Spent: 20m > Remaining Estimate: 0h > > This class is only used one place in Geode, and that is to check for an > exception of that type. It will never be thrown. Let's take it out. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5529) Remove SchedulingOrder
[ https://issues.apache.org/jira/browse/GEODE-5529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16570689#comment-16570689 ] ASF subversion and git services commented on GEODE-5529: Commit 3a72da70bdbd9aa848939d9406c4e3bad2a950d8 in geode's branch refs/heads/develop from [~gosullivan] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=3a72da7 ] GEODE-5529: remove SchedulingOrder. (#2261) > Remove SchedulingOrder > -- > > Key: GEODE-5529 > URL: https://issues.apache.org/jira/browse/GEODE-5529 > Project: Geode > Issue Type: Task > Components: tests >Reporter: Galen O'Sullivan >Assignee: Galen O'Sullivan >Priority: Major > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > This class is only used one place in Geode, and that is to check for an > exception of that type. It will never be thrown. Let's take it out. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5487) Choice of detect read conflict on transaction commit on a per-region basis.
[ https://issues.apache.org/jira/browse/GEODE-5487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-5487: -- Labels: pull-request-available (was: ) > Choice of detect read conflict on transaction commit on a per-region basis. > --- > > Key: GEODE-5487 > URL: https://issues.apache.org/jira/browse/GEODE-5487 > Project: Geode > Issue Type: Improvement > Components: transactions >Reporter: Eugene Nedzvetsky >Priority: Major > Labels: pull-request-available > > Geode supports detect read conflict(-Dgemfire.detectReadConflicts=true) on > transaction commit(see > https://geode.apache.org/docs/guide/11/developing/transactions/transaction_semantics.html) > This functionality can be enabled only on application level. It can > dramatically decrease application performance. > I propose to add ability to setup this property per region basis. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-5521) After an exception is received from a remote server function execution, local threads should not send back result to client later
[
https://issues.apache.org/jira/browse/GEODE-5521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
nabarun reassigned GEODE-5521:
--
Assignee: nabarun
> After an exception is received from a remote server function execution, local
> threads should not send back result to client later
> -
>
> Key: GEODE-5521
> URL: https://issues.apache.org/jira/browse/GEODE-5521
> Project: Geode
> Issue Type: Bug
> Components: functions
>Reporter: nabarun
>Assignee: nabarun
>Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> In the method cmdExecute()
> if the local co-ordinator receives an FunctionException of type
> FunctionInvocationTargetException or QueryInvocationTargetException from the
> remote server, setException is called which sets the lastResultReceived flag.
> This flag prevents other results from other threads to be sent to the client,
> as the client may have moved on.
> If there were any other function exception it will just send the exception
> but not set the flag.
> {code:java}
> if (cause instanceof FunctionInvocationTargetException
> || cause instanceof QueryInvocationTargetException) {
> if (cause instanceof InternalFunctionInvocationTargetException) {
> // Fix for #44709: User should not be aware of
> // InternalFunctionInvocationTargetException. No instance of
> // InternalFunctionInvocationTargetException is giving useful
> // information to user to take any corrective action hence logging
> // this at fine level logging
> // 1> When bucket is moved
> // 2> Incase of HA FucntionInvocationTargetException thrown. Since
> // it is HA, fucntion will be reexecuted on right node
> // 3> Multiple target nodes found for single hop operation
> // 4> in case of HA member departed
> if (logger.isDebugEnabled()) {
> logger.debug(LocalizedMessage.create(
>
> LocalizedStrings.ExecuteFunction_EXCEPTION_ON_SERVER_WHILE_EXECUTIONG_FUNCTION_0,
> new Object[] {function}), fe);
> }
> } else if (functionObject.isHA()) {
> logger.warn(LocalizedMessage.create(
>
> LocalizedStrings.ExecuteRegionFunction_EXCEPTION_ON_SERVER_WHILE_EXECUTIONG_FUNCTION_0,
> function + " :" + message));
> } else {
> logger.warn(LocalizedMessage.create(
>
> LocalizedStrings.ExecuteRegionFunction_EXCEPTION_ON_SERVER_WHILE_EXECUTIONG_FUNCTION_0,
> function), fe);
> }
> resultSender.setException(fe);
> } else {
> if(!resultSender.isLastResultReceived()){
> resultSender.setLastResultReceived(true);
> logger.warn(LocalizedMessage.create(
>
> LocalizedStrings.ExecuteRegionFunction_EXCEPTION_ON_SERVER_WHILE_EXECUTIONG_FUNCTION_0,
> function), fe);
> sendException(hasResult, clientMessage, message, serverConnection,
> fe);
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5532) Add isPaused to GatewaySender or change pause to be synchronous
[ https://issues.apache.org/jira/browse/GEODE-5532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16570572#comment-16570572 ] Kirk Lund commented on GEODE-5532: -- See AbstractGatewaySenderEventProcessor.awaitForDispatcherToPause() > Add isPaused to GatewaySender or change pause to be synchronous > --- > > Key: GEODE-5532 > URL: https://issues.apache.org/jira/browse/GEODE-5532 > Project: Geode > Issue Type: New Feature > Components: wan >Reporter: Kirk Lund >Priority: Major > > This feature is needed to remove flakiness from AsyncEventQueue and Wan tests > without using thread sleeps. > Tests such as AsyncEventListenerDistributedTest need to pause the > GatewaySender and then do some work after every dispatcher thread has > successfully paused. These tests currently sleep for one second after pausing > the GatewaySender. In order to convert the thread sleep to an Awaitility > call, we need an isPaused() method added to GatewaySender or we need to > change pause() to be synchronous. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5502) Cluster configuration can contain member-specific gateway receiver definitions which cause members to fail to start during rolling
[
https://issues.apache.org/jira/browse/GEODE-5502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16570542#comment-16570542
]
ASF subversion and git services commented on GEODE-5502:
Commit 0dd8c2c6db97d13b8d59af12265af496e978fab8 in geode's branch
refs/heads/feature/GEODE-5502 from [~barry.oglesby]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=0dd8c2c ]
GEODE-5502: Added additional test
> Cluster configuration can contain member-specific gateway receiver
> definitions which cause members to fail to start during rolling
> --
>
> Key: GEODE-5502
> URL: https://issues.apache.org/jira/browse/GEODE-5502
> Project: Geode
> Issue Type: Bug
> Components: configuration
>Reporter: Barry Oglesby
>Assignee: Barry Oglesby
>Priority: Major
> Labels: pull-request-available, swat
> Time Spent: 1h
> Remaining Estimate: 0h
>
> In versions before 1.4.0, cluster configuration could contain multiple
> member-specific gateway receiver definitions like:
> {noformat}
>
>
>
>
> {noformat}
> Starting in 1.4.0, multiple receivers are no longer allowed, so a
> configuration like this causes the member to throw an exception and fail to
> start.
> These member-specific receivers should be removed before sending the cluster
> configuration to new members to avoid attempting to create multiple receivers
> in a single member.
> Note: In this case, the member will start with no receivers.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-5433) Certain indexes are not properly updated during gii with stale persistent data
[ https://issues.apache.org/jira/browse/GEODE-5433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Huynh resolved GEODE-5433. Resolution: Fixed This was merged in as 9e7db8602df299af57d2ea824ba656fd24d54600 The issue was that the index was getting a callback after the value was modified. So the index was unable to correctly remove and update the index. > Certain indexes are not properly updated during gii with stale persistent data > -- > > Key: GEODE-5433 > URL: https://issues.apache.org/jira/browse/GEODE-5433 > Project: Geode > Issue Type: Bug > Components: querying >Affects Versions: 1.0.0-incubating >Reporter: Jason Huynh >Assignee: Jason Huynh >Priority: Major > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > Depending on what from clause is used in the index, gii'd data can > potentially lead to corrupted indexes. This is because the index updates are > being done after the gii process has modified the value, meaning the index > cannot calculate the correct old key. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-5532) Add isPaused to GatewaySender or change pause to be synchronous
[ https://issues.apache.org/jira/browse/GEODE-5532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund reassigned GEODE-5532: Assignee: Kirk Lund > Add isPaused to GatewaySender or change pause to be synchronous > --- > > Key: GEODE-5532 > URL: https://issues.apache.org/jira/browse/GEODE-5532 > Project: Geode > Issue Type: New Feature > Components: wan >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > > This feature is needed to remove flakiness from AsyncEventQueue and Wan tests > without using thread sleeps. > Tests such as AsyncEventListenerDistributedTest need to pause the > GatewaySender and then do some work after every dispatcher thread has > successfully paused. These tests currently sleep for one second after pausing > the GatewaySender. In order to convert the thread sleep to an Awaitility > call, we need an isPaused() method added to GatewaySender or we need to > change pause() to be synchronous. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-5525) Increase org.gradle.jvmargs from 2 GB to 3 GB in gradle.properties
[ https://issues.apache.org/jira/browse/GEODE-5525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund resolved GEODE-5525. -- Resolution: Fixed Fix Version/s: 1.7.0 > Increase org.gradle.jvmargs from 2 GB to 3 GB in gradle.properties > -- > > Key: GEODE-5525 > URL: https://issues.apache.org/jira/browse/GEODE-5525 > Project: Geode > Issue Type: Wish > Components: build >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Labels: pull-request-available > Fix For: 1.7.0 > > Time Spent: 20m > Remaining Estimate: 0h > > After the recent upgrade to Gradle 4.8, more Geode developers are hitting > OutOfMemoryError while building Geode. The folks who have created a > ~/.gradle/gradle.properties and specified org.gradle.jvmargs = -Xmx4g have > reported that this fixes the issue. I'd like to try increasing > geode/gradle.properties to use -Xmx3g to see if that's sufficient -- if not > then I'll raise it to 4g. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5257) ComparisonFailure in ShorteningExpirationTimeRegressionTest.customEntryTimeToLiveCanBeShortened
[
https://issues.apache.org/jira/browse/GEODE-5257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao updated GEODE-5257:
---
Labels: swat (was: )
> ComparisonFailure in
> ShorteningExpirationTimeRegressionTest.customEntryTimeToLiveCanBeShortened
> ---
>
> Key: GEODE-5257
> URL: https://issues.apache.org/jira/browse/GEODE-5257
> Project: Geode
> Issue Type: Bug
> Components: regions
>Reporter: Dale Emery
>Priority: Major
> Labels: swat
>
> [http://precheckin.gemfire.pivotal.io/teams/main/pipelines/dale-pr-1994/jobs/integrationTest/builds/1]
> The PR that invoked this precheckin changed a single line in the Spotless
> configuration. It is extremely unlikely that the failure is related to that
> change.
> {noformat}
> org.apache.geode.cache30.ShorteningExpirationTimeRegressionTest >
> customEntryTimeToLiveCanBeShortened FAILED
> org.junit.ComparisonFailure: expected:<"quickExpire"> but was:
> 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.cache30.ShorteningExpirationTimeRegressionTest.customEntryTimeToLiveCanBeShortened(ShorteningExpirationTimeRegressionTest.java:103)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5257) ComparisonFailure in ShorteningExpirationTimeRegressionTest.customEntryTimeToLiveCanBeShortened
[
https://issues.apache.org/jira/browse/GEODE-5257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16570488#comment-16570488
]
Jinmei Liao commented on GEODE-5257:
failed in a recent build:
https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/IntegrationTest/builds/207
> ComparisonFailure in
> ShorteningExpirationTimeRegressionTest.customEntryTimeToLiveCanBeShortened
> ---
>
> Key: GEODE-5257
> URL: https://issues.apache.org/jira/browse/GEODE-5257
> Project: Geode
> Issue Type: Bug
> Components: regions
>Reporter: Dale Emery
>Priority: Major
> Labels: swat
>
> [http://precheckin.gemfire.pivotal.io/teams/main/pipelines/dale-pr-1994/jobs/integrationTest/builds/1]
> The PR that invoked this precheckin changed a single line in the Spotless
> configuration. It is extremely unlikely that the failure is related to that
> change.
> {noformat}
> org.apache.geode.cache30.ShorteningExpirationTimeRegressionTest >
> customEntryTimeToLiveCanBeShortened FAILED
> org.junit.ComparisonFailure: expected:<"quickExpire"> but was:
> 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.cache30.ShorteningExpirationTimeRegressionTest.customEntryTimeToLiveCanBeShortened(ShorteningExpirationTimeRegressionTest.java:103)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5499) SUPERFLAKY: DistributedNoAckRegionOffHeapDUnitTest.testTXRmtMirror
[
https://issues.apache.org/jira/browse/GEODE-5499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16570485#comment-16570485
]
Jinmei Liao commented on GEODE-5499:
this failed again in recent build:
https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/208
> SUPERFLAKY: DistributedNoAckRegionOffHeapDUnitTest.testTXRmtMirror
> --
>
> Key: GEODE-5499
> URL: https://issues.apache.org/jira/browse/GEODE-5499
> Project: Geode
> Issue Type: Bug
>Reporter: Dan Smith
>Assignee: Dan Smith
>Priority: Major
> Labels: pull-request-available, swat
> Attachments: Test results - Class
> org.apache.geode.cache30.DistributedNoAckRegionOffHeapDUnitTest.html
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> This test is failing fairly frequently in CI
> {noformat}
> org.apache.geode.cache30.DistributedNoAckRegionOffHeapDUnitTest: 6 failures
> (98.101% success rate)
> | .testTXRmtMirror: 6 failures (98.101% success rate)
> | | Failed build 315 at
> https://concourse.apachegeode-ci.info/teams/staging/pipelines/mhansonp-pipelinework/jobs/DistributedTest/builds/315
> | | Failed build 296 at
> https://concourse.apachegeode-ci.info/teams/staging/pipelines/mhansonp-pipelinework/jobs/DistributedTest/builds/296
> | | Failed build 233 at
> https://concourse.apachegeode-ci.info/teams/staging/pipelines/mhansonp-pipelinework/jobs/DistributedTest/builds/233
> | | Failed build 123 at
> https://concourse.apachegeode-ci.info/teams/staging/pipelines/mhansonp-pipelinework/jobs/DistributedTest/builds/123
> | | Failed build 84 at
> https://concourse.apachegeode-ci.info/teams/staging/pipelines/mhansonp-pipelinework/jobs/DistributedTest/builds/84
> | | Failed build 51 at
> https://concourse.apachegeode-ci.info/teams/staging/pipelines/mhansonp-pipelinework/jobs/DistributedTest/builds/51
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-4934) CI Failure: GfshScript timing out intermittently waiting for execution to complete
[ https://issues.apache.org/jira/browse/GEODE-4934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16570474#comment-16570474 ] Jinmei Liao commented on GEODE-4934: more recent related failures: [https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/AcceptanceTest/builds/264] org.apache.geode.management.internal.cli.shell.StatusServerExitCodeAcceptanceTest > classMethod FAILED [ |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/AcceptanceTest/builds/264#L5b5b9fec:542] org.junit.ComparisonFailure: expected:<[0]> but was:<[1]> [ |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/AcceptanceTest/builds/264#L5b5b9fec:543] at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [ |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/AcceptanceTest/builds/264#L5b5b9fec:544] at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) [ |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/AcceptanceTest/builds/264#L5b5b9fec:545] at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) [ |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/AcceptanceTest/builds/264#L5b5b9fec:546] at org.apache.geode.test.junit.rules.gfsh.GfshScript.awaitIfNecessary(GfshScript.java:117) [ |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/AcceptanceTest/builds/264#L5b5b9fec:547] at org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:135) [ |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/AcceptanceTest/builds/264#L5b5b9fec:548] at org.apache.geode.test.junit.rules.gfsh.GfshScript.execute(GfshScript.java:106) [ |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/AcceptanceTest/builds/264#L5b5b9fec:549] at org.apache.geode.management.internal.cli.shell.StatusServerExitCodeAcceptanceTest.classSetup(StatusServerExitCodeAcceptanceTest.java:66) [ |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/AcceptanceTest/builds/264#L5b5b9fec:550] [ |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/AcceptanceTest/builds/264#L5b5b9fec:551] org.apache.geode.management.internal.cli.commands.DestroyIndexIfExistsTest > destroyIndexIfExists FAILED [ |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/AcceptanceTest/builds/264#L5b5b9fec:552] org.junit.ComparisonFailure: expected:<[0]> but was:<[1]> [ |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/AcceptanceTest/builds/264#L5b5b9fec:553] at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [ |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/AcceptanceTest/builds/264#L5b5b9fec:554] at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) [ |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/AcceptanceTest/builds/264#L5b5b9fec:555] at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) [ |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/AcceptanceTest/builds/264#L5b5b9fec:556] at org.apache.geode.test.junit.rules.gfsh.GfshScript.awaitIfNecessary(GfshScript.java:117) [ |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/AcceptanceTest/builds/264#L5b5b9fec:557] at org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:135) [ |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/AcceptanceTest/builds/264#L5b5b9fec:558] at org.apache.geode.test.junit.rules.gfsh.GfshScript.execute(GfshScript.java:106) [ |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/AcceptanceTest/builds/264#L5b5b9fec:559] at org.apache.geode.management.internal.cli.commands.DestroyIndexIfExistsTest.destroyIndexIfExists(DestroyIndexIfExistsTest.java:37) [ |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/AcceptanceTest/builds/264#L5b5b9fec:560] [ |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/AcceptanceTest/builds/264#L5b5b9fec:561] org.apache.geode.management.internal.cli.commands.ConfigureEvictionThroughGfsh > configureEvictionByObjectSizer FAILED [ |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/AcceptanceTest/builds/264#L5b5b9fec:562] org.junit.ComparisonFailure: expected:<[0]> but was:<[1]> [ |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/AcceptanceTest/builds/264#L5b5b9fec:563] at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [ |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/AcceptanceTest/builds/264#L5b5b9fec:564] at
[jira] [Updated] (GEODE-5531) gfsh echo variable does not work as documented
[
https://issues.apache.org/jira/browse/GEODE-5531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Derek Williams updated GEODE-5531:
--
Description:
Variables are [documented
here|http://geode.apache.org/docs/guide/16/tools_modules/gfsh/useful_gfsh_shell_variables.html]
to work with gfsh echo, but do not. This applies to both pre-defined shell
variables and user-defined variables (set variable...).
For example,
{code}
echo --string=$*`
{code}
will show all shell variables and values, but
{code}
echo --string=${SYS_USER}
{code}
simply displays ${SYS_USER}
Indeed,
[EchoCommand.java|https://github.com/apache/geode/blob/78dcf4b8fa86543e882365e78f1c8e2a623bffde/geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/EchoCommand.java]
has a special case for `$*`, but does not include the other documented cases.
was:
Variables are [documented
here|[http://geode.apache.org/docs/guide/16/tools_modules/gfsh/useful_gfsh_shell_variables.html]]
to work with gfsh `echo`, but do not. This applies to both pre-defined shell
variables and user-defined variables (`set variable`...).
For example, `echo --string=$*` will show all shell variables and values, but
`echo --string=${SYS_USER}` simply displays `${SYS_USER}`
Indeed,
[EchoCommand.java|[https://github.com/apache/geode/blob/78dcf4b8fa86543e882365e78f1c8e2a623bffde/geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/EchoCommand.java]]
has a special case for `$*`, but does not include the other documented cases.
> gfsh echo variable does not work as documented
> --
>
> Key: GEODE-5531
> URL: https://issues.apache.org/jira/browse/GEODE-5531
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Derek Williams
>Priority: Major
> Fix For: 1.6.0
>
>
> Variables are [documented
> here|http://geode.apache.org/docs/guide/16/tools_modules/gfsh/useful_gfsh_shell_variables.html]
> to work with gfsh echo, but do not. This applies to both pre-defined shell
> variables and user-defined variables (set variable...).
> For example,
> {code}
> echo --string=$*`
> {code}
> will show all shell variables and values, but
> {code}
> echo --string=${SYS_USER}
> {code}
> simply displays ${SYS_USER}
> Indeed,
> [EchoCommand.java|https://github.com/apache/geode/blob/78dcf4b8fa86543e882365e78f1c8e2a623bffde/geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/EchoCommand.java]
> has a special case for `$*`, but does not include the other documented cases.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5531) gfsh echo variable does not work as documented
[
https://issues.apache.org/jira/browse/GEODE-5531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Derek Williams updated GEODE-5531:
--
Description:
Variables are [documented
here|http://geode.apache.org/docs/guide/16/tools_modules/gfsh/useful_gfsh_shell_variables.html]
to work with gfsh echo, but do not. This applies to both pre-defined shell
variables and user-defined variables (set variable...).
For example,
{code}
echo --string=$*
{code}
will show all shell variables and values, but
{code}
echo --string=${SYS_USER}
{code}
simply displays ${SYS_USER}
Indeed,
[EchoCommand.java|https://github.com/apache/geode/blob/78dcf4b8fa86543e882365e78f1c8e2a623bffde/geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/EchoCommand.java]
has a special case for `$*`, but does not include the other documented cases.
was:
Variables are [documented
here|http://geode.apache.org/docs/guide/16/tools_modules/gfsh/useful_gfsh_shell_variables.html]
to work with gfsh echo, but do not. This applies to both pre-defined shell
variables and user-defined variables (set variable...).
For example,
{code}
echo --string=$*`
{code}
will show all shell variables and values, but
{code}
echo --string=${SYS_USER}
{code}
simply displays ${SYS_USER}
Indeed,
[EchoCommand.java|https://github.com/apache/geode/blob/78dcf4b8fa86543e882365e78f1c8e2a623bffde/geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/EchoCommand.java]
has a special case for `$*`, but does not include the other documented cases.
> gfsh echo variable does not work as documented
> --
>
> Key: GEODE-5531
> URL: https://issues.apache.org/jira/browse/GEODE-5531
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Derek Williams
>Priority: Major
> Fix For: 1.6.0
>
>
> Variables are [documented
> here|http://geode.apache.org/docs/guide/16/tools_modules/gfsh/useful_gfsh_shell_variables.html]
> to work with gfsh echo, but do not. This applies to both pre-defined shell
> variables and user-defined variables (set variable...).
> For example,
> {code}
> echo --string=$*
> {code}
> will show all shell variables and values, but
> {code}
> echo --string=${SYS_USER}
> {code}
> simply displays ${SYS_USER}
> Indeed,
> [EchoCommand.java|https://github.com/apache/geode/blob/78dcf4b8fa86543e882365e78f1c8e2a623bffde/geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/EchoCommand.java]
> has a special case for `$*`, but does not include the other documented cases.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5531) gfsh echo variable does not work as documented
[
https://issues.apache.org/jira/browse/GEODE-5531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Derek Williams updated GEODE-5531:
--
Description:
Variables are [documented
here|[http://geode.apache.org/docs/guide/16/tools_modules/gfsh/useful_gfsh_shell_variables.html]]
to work with gfsh `echo`, but do not. This applies to both pre-defined shell
variables and user-defined variables (`set variable`...).
For example, `echo --string=$*` will show all shell variables and values, but
`echo --string=${SYS_USER}` simply displays `${SYS_USER}`
Indeed,
[EchoCommand.java|[https://github.com/apache/geode/blob/78dcf4b8fa86543e882365e78f1c8e2a623bffde/geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/EchoCommand.java]]
has a special case for `$*`, but does not include the other documented cases.
was:
Variables are [documented
here](http://geode.apache.org/docs/guide/16/tools_modules/gfsh/useful_gfsh_shell_variables.html)
to work with gfsh `echo`, but do not. This applies to both pre-defined shell
variables and user-defined variables (`set variable`...).
For example, `echo --string=$*` will show all shell variables and values, but
`echo --string=${SYS_USER}` simply displays `${SYS_USER}`
Indeed,
[EchoCommand.java](https://github.com/apache/geode/blob/78dcf4b8fa86543e882365e78f1c8e2a623bffde/geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/EchoCommand.java)
has a special case for `$*`, but does not include the other documented cases.
> gfsh echo variable does not work as documented
> --
>
> Key: GEODE-5531
> URL: https://issues.apache.org/jira/browse/GEODE-5531
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Derek Williams
>Priority: Major
> Fix For: 1.6.0
>
>
> Variables are [documented
> here|[http://geode.apache.org/docs/guide/16/tools_modules/gfsh/useful_gfsh_shell_variables.html]]
> to work with gfsh `echo`, but do not. This applies to both pre-defined shell
> variables and user-defined variables (`set variable`...).
> For example, `echo --string=$*` will show all shell variables and values, but
> `echo --string=${SYS_USER}` simply displays `${SYS_USER}`
> Indeed,
> [EchoCommand.java|[https://github.com/apache/geode/blob/78dcf4b8fa86543e882365e78f1c8e2a623bffde/geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/EchoCommand.java]]
> has a special case for `$*`, but does not include the other documented cases.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-5475) ClusterStartupRule improvement
[ https://issues.apache.org/jira/browse/GEODE-5475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao resolved GEODE-5475. Resolution: Fixed > ClusterStartupRule improvement > -- > > Key: GEODE-5475 > URL: https://issues.apache.org/jira/browse/GEODE-5475 > Project: Geode > Issue Type: Improvement >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Labels: pull-request-available, swat > Time Spent: 50m > Remaining Estimate: 0h > > 1. stopMember actually stops both member and client (naming could be more > generic) > 2. startClient could use more convenience methods. > 3. stop(cleanWorkingDir) could be used by the ClientVM as well > 4. When locator is started, http service is started by default (when starting > on jmx manager). This slows down the test startup time. Only start http > service when needed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-5528) client event listener invoked multiple times for the same transactional operation
[
https://issues.apache.org/jira/browse/GEODE-5528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruce Schuchardt resolved GEODE-5528.
-
Resolution: Fixed
Fix Version/s: 1.8.0
> client event listener invoked multiple times for the same transactional
> operation
> -
>
> Key: GEODE-5528
> URL: https://issues.apache.org/jira/browse/GEODE-5528
> Project: Geode
> Issue Type: Bug
> Components: transactions
>Reporter: Bruce Schuchardt
>Assignee: Bruce Schuchardt
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.8.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> I observed a client cache's cache listener being invoked multiple times for
> the same transactional operation. The server handling the transaction commit
> was killed some time during the commit. Stats and logs seem to indicate that
> the commit had finished on the servers but the results had not been sent to
> the client. The client's stats show it retried the commit on another server
> and then got the results.
> Here are client logs for the transaction, which had a single destroy()
> operation:
> {noformat}
> [info 2018/07/13 18:24:00.506 PDT
> tid=0xbd]
> Committing transaction with id TXId:
> rs-2052RSFulla5i32xlarge-hydra-client-1(edgegemfire8_rs-2052RSFulla5i32xlarge-hydra-client-1_11909:11909:loner):34556:c8ff5e96:edgegemfire8_rs-2052RSFulla5i32xlarge-hydra-client-1_11909:2036
> [info 2018/07/13 18:24:02.659 PDT
> tid=0xbd]
> Invoked util.SilenceListener for key Object_19653: afterDestroy in edge8, pid
> 11909, vmID 25, operation DESTROY
> [info 2018/07/13 18:24:02.660 PDT
> tid=0xbd]
> Invoked util.SilenceListener for key Object_19653: afterDestroy in edge8, pid
> 11909, vmID 25, operation DESTROY
> [info 2018/07/13 18:24:02.660 PDT
> tid=0xbd]
> Invoked util.SilenceListener for key Object_19653: afterDestroy in edge8, pid
> 11909, vmID 25, operation DESTROY
> [info 2018/07/13 18:24:02.660 PDT
> tid=0xbd]
> Invoked util.SilenceListener for key Object_19653: afterDestroy in edge8, pid
> 11909, vmID 25, operation DESTROY
> [info 2018/07/13 18:24:02.660 PDT
> tid=0xbd]
> Invoked util.SilenceListener for key Object_19653: afterDestroy in edge8, pid
> 11909, vmID 25, operation DESTROY
> [info 2018/07/13 18:24:02.661 PDT
> tid=0xbd]
> Invoked util.SilenceListener for key Object_19653: afterDestroy in edge8, pid
> 11909, vmID 25, operation DESTROY
> [info 2018/07/13 18:24:02.661 PDT
> tid=0xbd]
> Invoked util.SilenceListener for key Object_19653: afterDestroy in edge8, pid
> 11909, vmID 25, operation DESTROY
> [info 2018/07/13 18:24:02.661 PDT
> tid=0xbd]
> Invoked util.SilenceListener for key Object_19653: afterDestroy in edge8, pid
> 11909, vmID 25, operation DESTROY
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5528) client event listener invoked multiple times for the same transactional operation
[
https://issues.apache.org/jira/browse/GEODE-5528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16570443#comment-16570443
]
ASF subversion and git services commented on GEODE-5528:
Commit 6cc75bb72d50147a6e2921f0c10bb6085315b85d in geode's branch
refs/heads/develop from [~bschuchardt]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=6cc75bb ]
GEODE-5528: client event listener invoked multiple times for the same
transactional operation
TXCommitMessage.combine() was checking to see if a RegionCommit was already
in its collection by using Collection.contains() but RegionCommit doesn't
implement equals() so this check would return false even if the collection
had a RegionCommit for the same Region.
The fix is to check for the region's path instead.
This closes #2260
> client event listener invoked multiple times for the same transactional
> operation
> -
>
> Key: GEODE-5528
> URL: https://issues.apache.org/jira/browse/GEODE-5528
> Project: Geode
> Issue Type: Bug
> Components: transactions
>Reporter: Bruce Schuchardt
>Assignee: Bruce Schuchardt
>Priority: Major
> Labels: pull-request-available
> Time Spent: 50m
> Remaining Estimate: 0h
>
> I observed a client cache's cache listener being invoked multiple times for
> the same transactional operation. The server handling the transaction commit
> was killed some time during the commit. Stats and logs seem to indicate that
> the commit had finished on the servers but the results had not been sent to
> the client. The client's stats show it retried the commit on another server
> and then got the results.
> Here are client logs for the transaction, which had a single destroy()
> operation:
> {noformat}
> [info 2018/07/13 18:24:00.506 PDT
> tid=0xbd]
> Committing transaction with id TXId:
> rs-2052RSFulla5i32xlarge-hydra-client-1(edgegemfire8_rs-2052RSFulla5i32xlarge-hydra-client-1_11909:11909:loner):34556:c8ff5e96:edgegemfire8_rs-2052RSFulla5i32xlarge-hydra-client-1_11909:2036
> [info 2018/07/13 18:24:02.659 PDT
> tid=0xbd]
> Invoked util.SilenceListener for key Object_19653: afterDestroy in edge8, pid
> 11909, vmID 25, operation DESTROY
> [info 2018/07/13 18:24:02.660 PDT
> tid=0xbd]
> Invoked util.SilenceListener for key Object_19653: afterDestroy in edge8, pid
> 11909, vmID 25, operation DESTROY
> [info 2018/07/13 18:24:02.660 PDT
> tid=0xbd]
> Invoked util.SilenceListener for key Object_19653: afterDestroy in edge8, pid
> 11909, vmID 25, operation DESTROY
> [info 2018/07/13 18:24:02.660 PDT
> tid=0xbd]
> Invoked util.SilenceListener for key Object_19653: afterDestroy in edge8, pid
> 11909, vmID 25, operation DESTROY
> [info 2018/07/13 18:24:02.660 PDT
> tid=0xbd]
> Invoked util.SilenceListener for key Object_19653: afterDestroy in edge8, pid
> 11909, vmID 25, operation DESTROY
> [info 2018/07/13 18:24:02.661 PDT
> tid=0xbd]
> Invoked util.SilenceListener for key Object_19653: afterDestroy in edge8, pid
> 11909, vmID 25, operation DESTROY
> [info 2018/07/13 18:24:02.661 PDT
> tid=0xbd]
> Invoked util.SilenceListener for key Object_19653: afterDestroy in edge8, pid
> 11909, vmID 25, operation DESTROY
> [info 2018/07/13 18:24:02.661 PDT
> tid=0xbd]
> Invoked util.SilenceListener for key Object_19653: afterDestroy in edge8, pid
> 11909, vmID 25, operation DESTROY
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-5531) gfsh echo variable does not work as documented
Derek Williams created GEODE-5531:
-
Summary: gfsh echo variable does not work as documented
Key: GEODE-5531
URL: https://issues.apache.org/jira/browse/GEODE-5531
Project: Geode
Issue Type: Bug
Components: gfsh
Reporter: Derek Williams
Fix For: 1.6.0
Variables are [documented
here](http://geode.apache.org/docs/guide/16/tools_modules/gfsh/useful_gfsh_shell_variables.html)
to work with gfsh `echo`, but do not. This applies to both pre-defined shell
variables and user-defined variables (`set variable`...).
For example, `echo --string=$*` will show all shell variables and values, but
`echo --string=${SYS_USER}` simply displays `${SYS_USER}`
Indeed,
[EchoCommand.java](https://github.com/apache/geode/blob/78dcf4b8fa86543e882365e78f1c8e2a623bffde/geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/EchoCommand.java)
has a special case for `$*`, but does not include the other documented cases.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5475) ClusterStartupRule improvement
[ https://issues.apache.org/jira/browse/GEODE-5475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16570427#comment-16570427 ] ASF subversion and git services commented on GEODE-5475: Commit 13bfcb0818d1f2488b90c41786e0733bc34c59d4 in geode's branch refs/heads/develop from jinmeiliao [ https://gitbox.apache.org/repos/asf?p=geode.git;h=13bfcb0 ] GEODE-5475: do not start http service by default (#2211) > ClusterStartupRule improvement > -- > > Key: GEODE-5475 > URL: https://issues.apache.org/jira/browse/GEODE-5475 > Project: Geode > Issue Type: Improvement >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Labels: pull-request-available, swat > Time Spent: 50m > Remaining Estimate: 0h > > 1. stopMember actually stops both member and client (naming could be more > generic) > 2. startClient could use more convenience methods. > 3. stop(cleanWorkingDir) could be used by the ClientVM as well > 4. When locator is started, http service is started by default (when starting > on jmx manager). This slows down the test startup time. Only start http > service when needed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-5520) Inconsistency created by delta-propagation interaction with concurrency control
[ https://issues.apache.org/jira/browse/GEODE-5520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruce Schuchardt resolved GEODE-5520. - Resolution: Fixed Fix Version/s: 1.8.0 > Inconsistency created by delta-propagation interaction with concurrency > control > --- > > Key: GEODE-5520 > URL: https://issues.apache.org/jira/browse/GEODE-5520 > Project: Geode > Issue Type: Bug > Components: client/server, messaging, regions, serialization >Reporter: Bruce Schuchardt >Assignee: Bruce Schuchardt >Priority: Major > Labels: pull-request-available > Fix For: 1.8.0 > > Time Spent: 20m > Remaining Estimate: 0h > > I tracked a cache inconsistency down to a delta propagation operation that > failed over from one server to another and then failed to apply the delta on > the new server. > When the full value is sent from the client the message is not marked as a > possible-duplicate. Because it was missing this flag the server did not try > to recover a concurrency version tag for the operation but instead generated > a new version. > When this server propagated the operation to another server it was rejected > by that server because it had already processed the operation from the > client's original attempt. It recognized this by way of the operation's > EventID being recorded in its EventTracker. > This resulted in one server having version X and the other having version X+1 > for the entry. > The client then destroyed the same entry with the same server, generating > version X+1 in that server. When the server propagated the operation the > other server already had X+1 and threw a > ConcurrentCacheModificationException. The result was one server having a > tombstone for the entry and the other having the value from the > delta-propagation operation. > This can be fixed by setting the possible-duplicate flag on the message from > the client that contains the full value. The server will then search for a > concurrency version tag and use it instead of generating a new one. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-4858) refactor internal commands to use the public ClusterConfigService
[ https://issues.apache.org/jira/browse/GEODE-4858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16570294#comment-16570294 ] ASF subversion and git services commented on GEODE-4858: Commit 8b9ebaa483f6d9f4f96354a1c0dafa472ce39e8c in geode's branch refs/heads/develop from [~jens.deppe] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=8b9ebaa ] GEODE-4858: Update *DiskStore commands to use ResultModel and SingleGfshCommand (#1996) > refactor internal commands to use the public ClusterConfigService > - > > Key: GEODE-4858 > URL: https://issues.apache.org/jira/browse/GEODE-4858 > Project: Geode > Issue Type: Sub-task > Components: configuration >Reporter: Jinmei Liao >Priority: Major > Labels: pull-request-available > Time Spent: 24h 10m > Remaining Estimate: 0h > > # except the ones that would need to access the internal cluster > configuration regions, like importClusterConfigCommand, > exportClusterConfigCommand or deploy > # use the configuration object as much as possible to pass parameters to the > functions. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
