[jira] [Assigned] (GEODE-6837) FunctionStats reads a system property on every call
[ https://issues.apache.org/jira/browse/GEODE-6837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Ivanac reassigned GEODE-6837: --- Assignee: Mario Ivanac > FunctionStats reads a system property on every call > --- > > Key: GEODE-6837 > URL: https://issues.apache.org/jira/browse/GEODE-6837 > Project: Geode > Issue Type: Improvement > Components: core >Reporter: Darrel Schneider >Assignee: Mario Ivanac >Priority: Major > Labels: performance > > The FunctionStats class has a isDisabled method that always reads a system > property. > Since system properties are stored in a synchronized HashTable this can hurt > concurrent function execution performance. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-6842) Possible ClassCastException in HAEventWrapper during concurrent client registration and queue GII
[ https://issues.apache.org/jira/browse/GEODE-6842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McMahon resolved GEODE-6842. - Resolution: Fixed Fix Version/s: 1.10.0 > Possible ClassCastException in HAEventWrapper during concurrent client > registration and queue GII > - > > Key: GEODE-6842 > URL: https://issues.apache.org/jira/browse/GEODE-6842 > Project: Geode > Issue Type: Bug > Components: client queues, client/server >Affects Versions: 1.10.0 >Reporter: Ryan McMahon >Assignee: Ryan McMahon >Priority: Major > Fix For: 1.10.0 > > Time Spent: 1h 20m > Remaining Estimate: 0h > > It is possible for a ClassCastException to be thrown if a client is > registering interest/CQ concurrently while a queue GII is being performed. > The issue is that the queued event (HAEventWrapper) can be mutated by the > client registration logic while it is in another client's queue, so if a GII > occurs it could be serialized while being mutated. Specifically, the > CqNameToOpHashMap was shown to throw the exception on the deserialization > side, because of a map size/entries mismatch on the serialization side caused > by the race described above. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GEODE-6842) Possible ClassCastException in HAEventWrapper during concurrent client registration and queue GII
[ https://issues.apache.org/jira/browse/GEODE-6842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McMahon closed GEODE-6842. --- > Possible ClassCastException in HAEventWrapper during concurrent client > registration and queue GII > - > > Key: GEODE-6842 > URL: https://issues.apache.org/jira/browse/GEODE-6842 > Project: Geode > Issue Type: Bug > Components: client queues, client/server >Affects Versions: 1.10.0 >Reporter: Ryan McMahon >Assignee: Ryan McMahon >Priority: Major > Fix For: 1.10.0 > > Time Spent: 1h 20m > Remaining Estimate: 0h > > It is possible for a ClassCastException to be thrown if a client is > registering interest/CQ concurrently while a queue GII is being performed. > The issue is that the queued event (HAEventWrapper) can be mutated by the > client registration logic while it is in another client's queue, so if a GII > occurs it could be serialized while being mutated. Specifically, the > CqNameToOpHashMap was shown to throw the exception on the deserialization > side, because of a map size/entries mismatch on the serialization side caused > by the race described above. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-6797) Possibility for missing dependencies in session state modules
[
https://issues.apache.org/jira/browse/GEODE-6797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McMahon resolved GEODE-6797.
-
Resolution: Fixed
Fix Version/s: 1.10.0
> Possibility for missing dependencies in session state modules
> -
>
> Key: GEODE-6797
> URL: https://issues.apache.org/jira/browse/GEODE-6797
> Project: Geode
> Issue Type: Bug
> Components: build
>Reporter: Ryan McMahon
>Assignee: Ryan McMahon
>Priority: Major
> Labels: GeodeCommons
> Fix For: 1.10.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> It was found that the AppServer module in Geode 1.9.0 release package is
> missing a dependency, specifically `geode-modules-1.9.0`. This appears to be
> due to the way we are zipping the module and specifying its dependencies in
> Gradle.
> From Dan Smith:
>
> {noformat}
> The basic issue is that this task includes the module jar in the zip in weird
> way, but doesn't declare the jar task as a dependency (in
> geode-modules-assembly/build.gradle):
> task distAppServer(type: Zip, dependsOn:
> [':extensions:geode-modules-session:jar',
> ':extensions:geode-modules-session-internal:jar',
> ':extensions:geode-modules-tomcat7:jar',
> ':extensions:geode-modules-tomcat8:jar',
> ':extensions:geode-modules-tomcat9:jar']) {
> baseName = moduleBaseName
> classifier = "AppServer"
> into('lib') {
> from getJarArtifact(':extensions:geode-modules-session')
> from getJarArtifact(':extensions:geode-modules-session-internal')
> from getJarArtifact(':extensions:geode-modules')
> from configurations.slf4jDeps
> }
> So I think it's somewhat indeterminant if any given build contains that jar
> in the zip. If we run the distributedTest on that particular build, we would
> catch the issue, but that's not how our build works (at least for geode
> releases).
> {noformat}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (GEODE-6797) Possibility for missing dependencies in session state modules
[
https://issues.apache.org/jira/browse/GEODE-6797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McMahon closed GEODE-6797.
---
> Possibility for missing dependencies in session state modules
> -
>
> Key: GEODE-6797
> URL: https://issues.apache.org/jira/browse/GEODE-6797
> Project: Geode
> Issue Type: Bug
> Components: build
>Reporter: Ryan McMahon
>Assignee: Ryan McMahon
>Priority: Major
> Labels: GeodeCommons
> Fix For: 1.10.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> It was found that the AppServer module in Geode 1.9.0 release package is
> missing a dependency, specifically `geode-modules-1.9.0`. This appears to be
> due to the way we are zipping the module and specifying its dependencies in
> Gradle.
> From Dan Smith:
>
> {noformat}
> The basic issue is that this task includes the module jar in the zip in weird
> way, but doesn't declare the jar task as a dependency (in
> geode-modules-assembly/build.gradle):
> task distAppServer(type: Zip, dependsOn:
> [':extensions:geode-modules-session:jar',
> ':extensions:geode-modules-session-internal:jar',
> ':extensions:geode-modules-tomcat7:jar',
> ':extensions:geode-modules-tomcat8:jar',
> ':extensions:geode-modules-tomcat9:jar']) {
> baseName = moduleBaseName
> classifier = "AppServer"
> into('lib') {
> from getJarArtifact(':extensions:geode-modules-session')
> from getJarArtifact(':extensions:geode-modules-session-internal')
> from getJarArtifact(':extensions:geode-modules')
> from configurations.slf4jDeps
> }
> So I think it's somewhat indeterminant if any given build contains that jar
> in the zip. If we run the distributedTest on that particular build, we would
> catch the issue, but that's not how our build works (at least for geode
> releases).
> {noformat}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-6845) Make logging consistent across putInProgress() calls in HAEventWrapper
[ https://issues.apache.org/jira/browse/GEODE-6845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McMahon reassigned GEODE-6845: --- Assignee: Ryan McMahon > Make logging consistent across putInProgress() calls in HAEventWrapper > -- > > Key: GEODE-6845 > URL: https://issues.apache.org/jira/browse/GEODE-6845 > Project: Geode > Issue Type: Improvement > Components: client queues, client/server >Reporter: Ryan McMahon >Assignee: Ryan McMahon >Priority: Major > > In some cases we logged when we incremented the putInProgress counter on an > HAEventWrapper while in others we do not, so we should probably be consistent > with logging and also indicate where the call is being made from (initial > put, GII queue, client registration). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-6845) Make logging consistent across putInProgress() calls in HAEventWrapper
Ryan McMahon created GEODE-6845: --- Summary: Make logging consistent across putInProgress() calls in HAEventWrapper Key: GEODE-6845 URL: https://issues.apache.org/jira/browse/GEODE-6845 Project: Geode Issue Type: Improvement Components: client queues, client/server Reporter: Ryan McMahon In some cases we logged when we incremented the putInProgress counter on an HAEventWrapper while in others we do not, so we should probably be consistent with logging and also indicate where the call is being made from (initial put, GII queue, client registration). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-6812) CI Failure: ParallelWANPropagationDUnitTest.testParallelPropagationPutBeforeSenderStart
[
https://issues.apache.org/jira/browse/GEODE-6812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16858197#comment-16858197
]
ASF subversion and git services commented on GEODE-6812:
Commit 94fd6d630b16ed437d48874ad4471f52b3559adf in geode's branch
refs/heads/feature/GEODE-6812 from eshu
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=94fd6d6 ]
GEODE-6812: Do not return null if waitToBecomeElder
* waitToBecomeElder could return false earlier without waiting if the node is
being shutdown.
* always return an elderState when waitToBecomeElder is true.
> CI Failure:
> ParallelWANPropagationDUnitTest.testParallelPropagationPutBeforeSenderStart
> ---
>
> Key: GEODE-6812
> URL: https://issues.apache.org/jira/browse/GEODE-6812
> Project: Geode
> Issue Type: Bug
> Components: distributed lock service, membership, wan
>Reporter: Robert Houghton
>Assignee: Eric Shu
>Priority: Major
> Labels: GeodeCommons
>
> Test testParallelPropagationPutBeforeSenderStart failed with the following:
> Uncaught exception during
> org.apache.geode.distributed.internal.locks.GrantorRequestProcessor$GrantorRequestMessage.basicProcess,
> when ElderState is null.
> Log:
> [http://files.apachegeode-ci.info/builds/apache-develop-main/1.10.0-SNAPSHOT.0298/test-results/distributedTest/1558945425/classes/org.apache.geode.internal.cache.wan.parallel.ParallelWANPropagationDUnitTest.html#testParallelPropagationPutBeforeSenderStart]
> Artifacts:
> [http://files.apachegeode-ci.info/builds/apache-develop-main/1.10.0-SNAPSHOT.0298/test-artifacts/1558945425/distributedtestfiles-OpenJDK8-1.10.0-SNAPSHOT.0298.tgz]
> Stacktrace:
> {noformat}
> java.lang.NullPointerException
> at
> org.apache.geode.distributed.internal.locks.GrantorRequestProcessor$GrantorRequestMessage.basicProcess(GrantorRequestProcessor.java:507)
> at
> org.apache.geode.distributed.internal.locks.GrantorRequestProcessor$GrantorRequestMessage.process(GrantorRequestProcessor.java:489)
> at
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:369)
> at
> org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:435)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.runUntilShutdown(ClusterDistributionManager.java:959)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.doProcessingThread(ClusterDistributionManager.java:825)
> at
> org.apache.geode.internal.logging.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:121)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-6842) Possible ClassCastException in HAEventWrapper during concurrent client registration and queue GII
[ https://issues.apache.org/jira/browse/GEODE-6842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16858190#comment-16858190 ] ASF subversion and git services commented on GEODE-6842: Commit 610992ae8ba1c8d26756606bb62e871ea846544f in geode's branch refs/heads/develop from Ryan McMahon [ https://gitbox.apache.org/repos/asf?p=geode.git;h=610992a ] GEODE-6842: Making serialization of CqNameToOpHashMap thread safe (#3680) By making the CqNameToOpHashMap derive from ConcurrentHashMap and taking a snapshot prior to serialization, we avoid a race where this map could be mutated by a client registration thread while a queue GII which includes this map is occuring in another thread. > Possible ClassCastException in HAEventWrapper during concurrent client > registration and queue GII > - > > Key: GEODE-6842 > URL: https://issues.apache.org/jira/browse/GEODE-6842 > Project: Geode > Issue Type: Bug > Components: client queues, client/server >Affects Versions: 1.10.0 >Reporter: Ryan McMahon >Assignee: Ryan McMahon >Priority: Major > Time Spent: 1h 20m > Remaining Estimate: 0h > > It is possible for a ClassCastException to be thrown if a client is > registering interest/CQ concurrently while a queue GII is being performed. > The issue is that the queued event (HAEventWrapper) can be mutated by the > client registration logic while it is in another client's queue, so if a GII > occurs it could be serialized while being mutated. Specifically, the > CqNameToOpHashMap was shown to throw the exception on the deserialization > side, because of a map size/entries mismatch on the serialization side caused > by the race described above. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-6797) Possibility for missing dependencies in session state modules
[
https://issues.apache.org/jira/browse/GEODE-6797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16858189#comment-16858189
]
ASF subversion and git services commented on GEODE-6797:
Commit 29f641996977dcebcf755ba6dada2882e04c5a95 in geode's branch
refs/heads/develop from Ryan McMahon
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=29f6419 ]
GEODE-6797: Use better packaging techniques to avoid missing dependency (#3673)
> Possibility for missing dependencies in session state modules
> -
>
> Key: GEODE-6797
> URL: https://issues.apache.org/jira/browse/GEODE-6797
> Project: Geode
> Issue Type: Bug
> Components: build
>Reporter: Ryan McMahon
>Assignee: Ryan McMahon
>Priority: Major
> Labels: GeodeCommons
> Time Spent: 40m
> Remaining Estimate: 0h
>
> It was found that the AppServer module in Geode 1.9.0 release package is
> missing a dependency, specifically `geode-modules-1.9.0`. This appears to be
> due to the way we are zipping the module and specifying its dependencies in
> Gradle.
> From Dan Smith:
>
> {noformat}
> The basic issue is that this task includes the module jar in the zip in weird
> way, but doesn't declare the jar task as a dependency (in
> geode-modules-assembly/build.gradle):
> task distAppServer(type: Zip, dependsOn:
> [':extensions:geode-modules-session:jar',
> ':extensions:geode-modules-session-internal:jar',
> ':extensions:geode-modules-tomcat7:jar',
> ':extensions:geode-modules-tomcat8:jar',
> ':extensions:geode-modules-tomcat9:jar']) {
> baseName = moduleBaseName
> classifier = "AppServer"
> into('lib') {
> from getJarArtifact(':extensions:geode-modules-session')
> from getJarArtifact(':extensions:geode-modules-session-internal')
> from getJarArtifact(':extensions:geode-modules')
> from configurations.slf4jDeps
> }
> So I think it's somewhat indeterminant if any given build contains that jar
> in the zip. If we run the distributedTest on that particular build, we would
> catch the issue, but that's not how our build works (at least for geode
> releases).
> {noformat}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-6616) Flaky: AutoConnectionSourceDUnitTest > testClientDynamicallyDropsStoppedLocator FAILED
[
https://issues.apache.org/jira/browse/GEODE-6616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16858170#comment-16858170
]
Barry Oglesby commented on GEODE-6616:
--
This issue happened again:
[https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/781]
> Flaky: AutoConnectionSourceDUnitTest >
> testClientDynamicallyDropsStoppedLocator FAILED
> --
>
> Key: GEODE-6616
> URL: https://issues.apache.org/jira/browse/GEODE-6616
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Mark Hanson
>Priority: Minor
>
> Failed connection..
> {noformat}
> [vm3] [info 2019/04/09 06:48:44.919 UTC
> tid=0x20] Got result: EXCEPTION_OCCURRED
> [vm3] org.apache.geode.cache.client.ServerOperationException: remote server
> on 16f27a14ad79(255:loner):52816:5f2bdb00: : While performing a remote put
> [vm3] at
> org.apache.geode.cache.client.internal.PutOp$PutOpImpl.processAck(PutOp.java:389)
> [vm3] at
> org.apache.geode.cache.client.internal.PutOp$PutOpImpl.processResponse(PutOp.java:313)
> [vm3] at
> org.apache.geode.cache.client.internal.PutOp$PutOpImpl.attemptReadResponse(PutOp.java:454)
> [vm3] at
> org.apache.geode.cache.client.internal.AbstractOp.attempt(AbstractOp.java:387)
> [vm3] at
> org.apache.geode.cache.client.internal.ConnectionImpl.execute(ConnectionImpl.java:289)
> [vm3] at
> org.apache.geode.cache.client.internal.pooling.PooledConnection.execute(PooledConnection.java:351)
> [vm3] at
> org.apache.geode.cache.client.internal.OpExecutorImpl.executeWithPossibleReAuthentication(OpExecutorImpl.java:908)
> [vm3] at
> org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:172)
> [vm3] at
> org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:130)
> [vm3] at
> org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:792)
> [vm3] at
> org.apache.geode.cache.client.internal.PutOp.execute(PutOp.java:90)
> [vm3] at
> org.apache.geode.cache.client.internal.ServerRegionProxy.put(ServerRegionProxy.java:155)
> [vm3] at
> org.apache.geode.internal.cache.LocalRegion.serverPut(LocalRegion.java:3070)
> [vm3] at
> org.apache.geode.internal.cache.LocalRegion.cacheWriteBeforePut(LocalRegion.java:3222)
> [vm3] at
> org.apache.geode.internal.cache.map.RegionMapPut.invokeCacheWriter(RegionMapPut.java:230)
> [vm3] at
> org.apache.geode.internal.cache.map.AbstractRegionMapPut.doPutIfPreconditionsSatisified(AbstractRegionMapPut.java:295)
> [vm3] at
> org.apache.geode.internal.cache.map.AbstractRegionMapPut.doPutOnSynchronizedRegionEntry(AbstractRegionMapPut.java:282)
> [vm3] at
> org.apache.geode.internal.cache.map.AbstractRegionMapPut.doPutOnRegionEntryInMap(AbstractRegionMapPut.java:273)
> [vm3] at
> org.apache.geode.internal.cache.map.AbstractRegionMapPut.addRegionEntryToMapAndDoPut(AbstractRegionMapPut.java:251)
> [vm3] at
> org.apache.geode.internal.cache.map.AbstractRegionMapPut.doPutRetryingIfNeeded(AbstractRegionMapPut.java:216)
> [vm3] at
> org.apache.geode.internal.cache.map.AbstractRegionMapPut.doWithIndexInUpdateMode(AbstractRegionMapPut.java:198)
> [vm3] at
> org.apache.geode.internal.cache.map.AbstractRegionMapPut.doPut(AbstractRegionMapPut.java:180)
> [vm3] at
> org.apache.geode.internal.cache.map.AbstractRegionMapPut.runWhileLockedForCacheModification(AbstractRegionMapPut.java:119)
> [vm3] at
> org.apache.geode.internal.cache.map.RegionMapPut.runWhileLockedForCacheModification(RegionMapPut.java:150)
> [vm3] at
> org.apache.geode.internal.cache.map.AbstractRegionMapPut.put(AbstractRegionMapPut.java:169)
> [vm3] at
> org.apache.geode.internal.cache.AbstractRegionMap.basicPut(AbstractRegionMap.java:2044)
> [vm3] at
> org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5695)
> [vm3] at
> org.apache.geode.internal.cache.LocalRegionDataView.putEntry(LocalRegionDataView.java:162)
> [vm3] at
> org.apache.geode.internal.cache.LocalRegion.basicPut(LocalRegion.java:5123)
> [vm3] at
> org.apache.geode.internal.cache.LocalRegion.validatedPut(LocalRegion.java:1652)
> [vm3] at
> org.apache.geode.internal.cache.LocalRegion.lambda$put$3(LocalRegion.java:1638)
> [vm3] at
> io.micrometer.core.instrument.composite.CompositeTimer.record(CompositeTimer.java:57)
> [vm3] at
> org.apache.geode.internal.cache.LocalRegion.put(LocalRegion.java:1634)
> [vm3] at
> org.apache.geode.internal.cache.AbstractRegion.put(AbstractRegion.java:425)
> [vm3]
[jira] [Commented] (GEODE-6812) CI Failure: ParallelWANPropagationDUnitTest.testParallelPropagationPutBeforeSenderStart
[ https://issues.apache.org/jira/browse/GEODE-6812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16858167#comment-16858167 ] Eric Shu commented on GEODE-6812: - As Bruce mentioned, this NPE occurs when the vm is being shut down. [vm5] [info 2019/05/27 07:17:24.126 GMT RMI TCP Connection(1)-172.17.0.9 tid=0x20] Shutting down DistributionManager 172.17.0.9(758)v2:41006. [vm5] [fatal 2019/05/27 07:17:24.128 GMT Pooled Message Processor 15 tid=0x4e6] Uncaught exception processing GrantorRequestMessage (service='__PRLS'; grantorVersion=2'; dlsSerialNumber=24'; processorId=13640'; opCode=CLEAR_OP'; oldT=null) [vm5] java.lang.NullPointerException [vm5] at org.apache.geode.distributed.internal.locks.GrantorRequestProcessor$GrantorRequestMessage.basicProcess(GrantorRequestProcessor.java:507) [vm5] at org.apache.geode.distributed.internal.locks.GrantorRequestProcessor$GrantorRequestMessage.process(GrantorRequestProcessor.java:489) [vm5] at org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:369) [vm5] at org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:435) [vm5] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [vm5] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [vm5] at org.apache.geode.distributed.internal.ClusterDistributionManager.runUntilShutdown(ClusterDistributionManager.java:959) [vm5] at org.apache.geode.distributed.internal.ClusterDistributionManager.doProcessingThread(ClusterDistributionManager.java:825) [vm5] at org.apache.geode.internal.logging.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:121) [vm5] at java.lang.Thread.run(Thread.java:748) This occurred after wan test finished and during test clean up. I think the cause of this NPE is that vm5 is supposedly to be the next elder, but it was removed from its view as a shunned member due to shut down; thus it could not become the elder. The following is the possible scenario what occurred: A current elder is being shut down during test clean up. vm5 is chosen to be the next elder (based on membership view), so another member node sends GrantorRequestMessage to vm5. When vm5 is processing this message request, itself is also being shut down. Here is the stack trace (with added logging) that a vm could add itself to the shunned member when it is being shutdown/disconnect. [vm5] at org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.addShunnedMember(GMSMembershipManager.java:2131) [vm5] at org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.destroyMember(GMSMembershipManager.java:1980) [vm5] at org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.stop(GMSMembershipManager.java:1516) [vm5] at org.apache.geode.distributed.internal.membership.gms.Services.stop(Services.java:245) [vm5] at org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.shutdown(GMSMembershipManager.java:1496) [vm5] at org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.disconnect(GMSMembershipManager.java:2634) [vm5] at org.apache.geode.distributed.internal.ClusterDistributionManager.uncleanShutdown(ClusterDistributionManager.java:1912) [vm5] at org.apache.geode.distributed.internal.ClusterDistributionManager.shutdown(ClusterDistributionManager.java:1606) [vm5] at org.apache.geode.distributed.internal.ClusterDistributionManager.close(ClusterDistributionManager.java:2111) [vm5] at org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect(InternalDistributedSystem.java:1571) [vm5] at org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect(InternalDistributedSystem.java:1195) [vm5] at org.apache.geode.internal.cache.GemFireCacheImpl.close(GemFireCacheImpl.java:2315) [vm5] at org.apache.geode.internal.cache.GemFireCacheImpl.close(GemFireCacheImpl.java:1874) [vm5] at org.apache.geode.internal.cache.GemFireCacheImpl.close(GemFireCacheImpl.java:1864) [vm5] at org.apache.geode.internal.cache.wan.WANTestBase.closeCache(WANTestBase.java:3798) [vm5] at org.apache.geode.internal.cache.wan.WANTestBase.cleanupVM(WANTestBase.java:3792) [vm5] at org.apache.geode.internal.cache.wan.WANTestBase.lambda$preTearDown$bb17a952$1(WANTestBase.java:3781) [vm5] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [vm5] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [vm5] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [vm5] at java.lang.reflect.Method.invoke(Method.java:498) [vm5] at org.apache.geode.test.dunit.internal.MethodInvoker.executeObject(MethodInvoker.java:123) [vm5] at
[jira] [Resolved] (GEODE-6546) Geode-Native User Guide - document 'putgetremove' example
[ https://issues.apache.org/jira/browse/GEODE-6546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Barnes resolved GEODE-6546. Resolution: Fixed Fix Version/s: 1.10.0 > Geode-Native User Guide - document 'putgetremove' example > - > > Key: GEODE-6546 > URL: https://issues.apache.org/jira/browse/GEODE-6546 > Project: Geode > Issue Type: Sub-task > Components: docs, native client >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Major > Fix For: 1.10.0 > > Time Spent: 1h 50m > Remaining Estimate: 0h > > Document the 'putgetremove' example. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-6623) GemFire Native Client Has a new declarative Cache Schema
[ https://issues.apache.org/jira/browse/GEODE-6623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Barnes resolved GEODE-6623. Fix Version/s: 1.10.0 > GemFire Native Client Has a new declarative Cache Schema > > > Key: GEODE-6623 > URL: https://issues.apache.org/jira/browse/GEODE-6623 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Charlie Black >Assignee: Dave Barnes >Priority: Major > Fix For: 1.10.0 > > Time Spent: 1h > Remaining Estimate: 0h > > GemFire Native Client Has a new declarative Cache Schema. The > documentation of the schema is missing. > As a user of GemFire Native client, I would like to know how to use the > schema and what is the meaning of the elements in the schema. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-6576) DB connection rebalancing improvement
[ https://issues.apache.org/jira/browse/GEODE-6576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Ivanac resolved GEODE-6576. - Resolution: Fixed > DB connection rebalancing improvement > - > > Key: GEODE-6576 > URL: https://issues.apache.org/jira/browse/GEODE-6576 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Mario Ivanac >Assignee: Mario Ivanac >Priority: Major > Labels: needs-review, pull-request-available > Fix For: 1.10.0 > > Time Spent: 1h 50m > Remaining Estimate: 0h > > When using min=max=120 connections, and about 2000 TPS it is observed, that > every 5 minutes (load-conditioning-interval) we get significant delays . But > I suspect you could reproduce it at any configuration, if you look for > increased delays when driver rebalances connections > (load-conditioning-interval). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-6844) Move private implementation into source files.
Matthew Reddington created GEODE-6844: - Summary: Move private implementation into source files. Key: GEODE-6844 URL: https://issues.apache.org/jira/browse/GEODE-6844 Project: Geode Issue Type: Improvement Components: native client Reporter: Matthew Reddington Function and method definitions across all header files within the "cppcache/src" directory are to be moved into their corresponding source files, source files created as necessary. "inline" and "explicit" are to be removed. Redundant "virtual" and "final" are to be removed. Derived destructors are to be marked override. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-6843) Move inline functions from TcrMessage out of header
[ https://issues.apache.org/jira/browse/GEODE-6843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16858121#comment-16858121 ] ASF subversion and git services commented on GEODE-6843: Commit 6054b8136fbae2cbcc13dc4c0a846ef8e48e7701 in geode-native's branch refs/heads/develop from Matthew Reddington [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=6054b81 ] GEODE-6843: Moved header implemenations into the source file where they belong. (#484) * Moved header implemenations into the source file where they belong. * Explicitly inlined read and write int. * Moved ~TcrMessageHelper() to public. * Defaulted derived class destructors. * Moved a unit test to it's proper location. > Move inline functions from TcrMessage out of header > --- > > Key: GEODE-6843 > URL: https://issues.apache.org/jira/browse/GEODE-6843 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Blake Bender >Priority: Major > > There are several methods on TcrMessage that are gratuitously declared with > the inline keyword in TcrMessage.h. Since everything includes this header, > any change to one of these methods necessitates building the world. Need to > move these method bodies into the .cpp file and let the compiler do the work > for us, as probably should've been done to begin with. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-6843) Move inline functions from TcrMessage out of header
Blake Bender created GEODE-6843: --- Summary: Move inline functions from TcrMessage out of header Key: GEODE-6843 URL: https://issues.apache.org/jira/browse/GEODE-6843 Project: Geode Issue Type: Improvement Components: native client Reporter: Blake Bender There are several methods on TcrMessage that are gratuitously declared with the inline keyword in TcrMessage.h. Since everything includes this header, any change to one of these methods necessitates building the world. Need to move these method bodies into the .cpp file and let the compiler do the work for us, as probably should've been done to begin with. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-2484) Remove ACE from native client dependencies
[ https://issues.apache.org/jira/browse/GEODE-2484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16858088#comment-16858088 ] ASF subversion and git services commented on GEODE-2484: Commit 9a7a05f2331b3a5312e3c6b79e605f66cf7380eb in geode-native's branch refs/heads/wip/no-ace-headers from Jacob Barrett [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=9a7a05f ] GEODE-2484: Removes time functions * Replaces with Boost Date Time library. > Remove ACE from native client dependencies > -- > > Key: GEODE-2484 > URL: https://issues.apache.org/jira/browse/GEODE-2484 > Project: Geode > Issue Type: Task > Components: native client >Reporter: David Kimura >Priority: Major > Labels: pull-request-available > Time Spent: 10.5h > Remaining Estimate: 0h > > Remove ACE from native client dependencies. > Replace ACE usage with C++11 and/or Boost 1.63+ -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-2484) Remove ACE from native client dependencies
[ https://issues.apache.org/jira/browse/GEODE-2484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16858089#comment-16858089 ] ASF subversion and git services commented on GEODE-2484: Commit 192559575cd2c73c4ecefff92d5ff2e134a57c9f in geode-native's branch refs/heads/wip/no-ace-headers from Jacob Barrett [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=1925595 ] GEODE-2484: Removes uname functions * Replaces uname with macros and boost. > Remove ACE from native client dependencies > -- > > Key: GEODE-2484 > URL: https://issues.apache.org/jira/browse/GEODE-2484 > Project: Geode > Issue Type: Task > Components: native client >Reporter: David Kimura >Priority: Major > Labels: pull-request-available > Time Spent: 10.5h > Remaining Estimate: 0h > > Remove ACE from native client dependencies. > Replace ACE usage with C++11 and/or Boost 1.63+ -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-6840) Update to ACE 6.5.5, google/benchmarks 1.5.0, SQLite 3.28.0
[ https://issues.apache.org/jira/browse/GEODE-6840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16858087#comment-16858087 ] ASF subversion and git services commented on GEODE-6840: Commit b0b101bf950e830a1225d83ac9aa1725694d427d in geode-native's branch refs/heads/wip/no-ace-headers from Jacob Barrett [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=b0b101b ] GEODE-6840: Upgrade third party dependencies * ACE 6.5.5 * google/benchmark 1.5.0 * SQLite 3.28.0 > Update to ACE 6.5.5, google/benchmarks 1.5.0, SQLite 3.28.0 > --- > > Key: GEODE-6840 > URL: https://issues.apache.org/jira/browse/GEODE-6840 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Jacob S. Barrett >Assignee: Jacob S. Barrett >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-6840) Update to ACE 6.5.5, google/benchmarks 1.5.0, SQLite 3.28.0
[ https://issues.apache.org/jira/browse/GEODE-6840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16858077#comment-16858077 ] ASF subversion and git services commented on GEODE-6840: Commit 87aadd010af22b4e877f23df883116b8d3a5bfb6 in geode-native's branch refs/heads/develop from Jacob Barrett [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=87aadd0 ] GEODE-6840: Upgrade third party dependencies (#492) * ACE 6.5.5 * google/benchmark 1.5.0 * SQLite 3.28.0 > Update to ACE 6.5.5, google/benchmarks 1.5.0, SQLite 3.28.0 > --- > > Key: GEODE-6840 > URL: https://issues.apache.org/jira/browse/GEODE-6840 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Jacob S. Barrett >Assignee: Jacob S. Barrett >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-6623) GemFire Native Client Has a new declarative Cache Schema
[ https://issues.apache.org/jira/browse/GEODE-6623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16858073#comment-16858073 ] ASF subversion and git services commented on GEODE-6623: Commit 81653f5b81d750511890f5a94808780d798eefa6 in geode-native's branch refs/heads/develop from Dave Barnes [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=81653f5 ] GEODE-6623: Native Client user guide - document the client-cache schema (#489) * Revised description of the system's default treatment of cache.xml * Deleted empty Default columns, filled in region-attribute defaults > GemFire Native Client Has a new declarative Cache Schema > > > Key: GEODE-6623 > URL: https://issues.apache.org/jira/browse/GEODE-6623 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Charlie Black >Assignee: Dave Barnes >Priority: Major > Time Spent: 50m > Remaining Estimate: 0h > > GemFire Native Client Has a new declarative Cache Schema. The > documentation of the schema is missing. > As a user of GemFire Native client, I would like to know how to use the > schema and what is the meaning of the elements in the schema. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-6802) Data/bucket (among redundant copies) inconsistence could occur after a member is lost
[ https://issues.apache.org/jira/browse/GEODE-6802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu resolved GEODE-6802. - Resolution: Fixed Fix Version/s: 1.10.0 > Data/bucket (among redundant copies) inconsistence could occur after a member > is lost > - > > Key: GEODE-6802 > URL: https://issues.apache.org/jira/browse/GEODE-6802 > Project: Geode > Issue Type: Bug > Components: persistence, regions >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Fix For: 1.10.0 > > Time Spent: 3.5h > Remaining Estimate: 0h > > When a prime bucket(or replicate region) is lost during the operation, it > could occur at a time it only sent the operation to only part of the > replicates (redundant copies), but not to others. Geode does region > synchronization after some delay using a timed task to sync with all other > members. > When the lost member restarted (or new nodes joined), it could request GII > from a source (before region sync occurred) did not receive the original > operation. This restarted member or new member does not have the timed task > which triggered by the original member departed event. This could lead to > data inconsistence among the members. > In addition, for persistent members, there could be some exception occurred > during GII, and region synchronization provider would not send necessary data > to the requester and thus lead to data inconsistency. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-6802) Data/bucket (among redundant copies) inconsistence could occur after a member is lost
[ https://issues.apache.org/jira/browse/GEODE-6802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16858057#comment-16858057 ] ASF subversion and git services commented on GEODE-6802: Commit da960f389d5c54a23f6bfa33363b637b550bafb4 in geode's branch refs/heads/feature/GEODE-6802 from eshu [ https://gitbox.apache.org/repos/asf?p=geode.git;h=da960f3 ] GEODE-6802: Execute region synchronization on newly joined member. * Region sync will be invoked to avoid data inconsistency on a newly joined/restarted member if it received a region synchronization request from other members due to timed task. * Use a flag in RegionVersionHolder to ensure only one such call is executed. * Make sure RVV exception is filled for persistent member requesting region sync. (This may leads to CommitConflictException on some transactions on persistent regions due to this region sync operation. But it should be rare and is acceptable compared to data inconsistency issue.) > Data/bucket (among redundant copies) inconsistence could occur after a member > is lost > - > > Key: GEODE-6802 > URL: https://issues.apache.org/jira/browse/GEODE-6802 > Project: Geode > Issue Type: Bug > Components: persistence, regions >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Time Spent: 3.5h > Remaining Estimate: 0h > > When a prime bucket(or replicate region) is lost during the operation, it > could occur at a time it only sent the operation to only part of the > replicates (redundant copies), but not to others. Geode does region > synchronization after some delay using a timed task to sync with all other > members. > When the lost member restarted (or new nodes joined), it could request GII > from a source (before region sync occurred) did not receive the original > operation. This restarted member or new member does not have the timed task > which triggered by the original member departed event. This could lead to > data inconsistence among the members. > In addition, for persistent members, there could be some exception occurred > during GII, and region synchronization provider would not send necessary data > to the requester and thus lead to data inconsistency. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-6802) Data/bucket (among redundant copies) inconsistence could occur after a member is lost
[ https://issues.apache.org/jira/browse/GEODE-6802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16858055#comment-16858055 ] ASF subversion and git services commented on GEODE-6802: Commit 5d300cfedc7046f0ac4b12e5dbcde7a4606bb6ec in geode's branch refs/heads/develop from Eric Shu [ https://gitbox.apache.org/repos/asf?p=geode.git;h=5d300cf ] GEODE-6802: Execute region synchronization on newly joined member. (#3623) * Region sync will be invoked to avoid data inconsistency on a newly joined/restarted member if it received a region synchronization request from other members due to timed task. * Use a flag in RegionVersionHolder to ensure only one such call is executed. * Make sure RVV exception is filled for persistent member requesting region sync. (This may leads to CommitConflictException on some transactions on persistent regions due to this region sync operation. But it should be rare and is acceptable compared to data inconsistency issue.) > Data/bucket (among redundant copies) inconsistence could occur after a member > is lost > - > > Key: GEODE-6802 > URL: https://issues.apache.org/jira/browse/GEODE-6802 > Project: Geode > Issue Type: Bug > Components: persistence, regions >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Time Spent: 3.5h > Remaining Estimate: 0h > > When a prime bucket(or replicate region) is lost during the operation, it > could occur at a time it only sent the operation to only part of the > replicates (redundant copies), but not to others. Geode does region > synchronization after some delay using a timed task to sync with all other > members. > When the lost member restarted (or new nodes joined), it could request GII > from a source (before region sync occurred) did not receive the original > operation. This restarted member or new member does not have the timed task > which triggered by the original member departed event. This could lead to > data inconsistence among the members. > In addition, for persistent members, there could be some exception occurred > during GII, and region synchronization provider would not send necessary data > to the requester and thus lead to data inconsistency. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-6842) Possible ClassCastException in HAEventWrapper during concurrent client registration and queue GII
[ https://issues.apache.org/jira/browse/GEODE-6842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McMahon reassigned GEODE-6842: --- Assignee: Ryan McMahon > Possible ClassCastException in HAEventWrapper during concurrent client > registration and queue GII > - > > Key: GEODE-6842 > URL: https://issues.apache.org/jira/browse/GEODE-6842 > Project: Geode > Issue Type: Bug > Components: client queues, client/server >Affects Versions: 1.10.0 >Reporter: Ryan McMahon >Assignee: Ryan McMahon >Priority: Major > > It is possible for a ClassCastException to be thrown if a client is > registering interest/CQ concurrently while a queue GII is being performed. > The issue is that the queued event (HAEventWrapper) can be mutated by the > client registration logic while it is in another client's queue, so if a GII > occurs it could be serialized while being mutated. Specifically, the > CqNameToOpHashMap was shown to throw the exception on the deserialization > side, because of a map size/entries mismatch on the serialization side caused > by the race described above. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-6842) Possible ClassCastException in HAEventWrapper during concurrent client registration and queue GII
[ https://issues.apache.org/jira/browse/GEODE-6842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McMahon updated GEODE-6842: Affects Version/s: 1.10.0 > Possible ClassCastException in HAEventWrapper during concurrent client > registration and queue GII > - > > Key: GEODE-6842 > URL: https://issues.apache.org/jira/browse/GEODE-6842 > Project: Geode > Issue Type: Bug > Components: client queues, client/server >Affects Versions: 1.10.0 >Reporter: Ryan McMahon >Priority: Major > > It is possible for a ClassCastException to be thrown if a client is > registering interest/CQ concurrently while a queue GII is being performed. > The issue is that the queued event (HAEventWrapper) can be mutated by the > client registration logic while it is in another client's queue, so if a GII > occurs it could be serialized while being mutated. Specifically, the > CqNameToOpHashMap was shown to throw the exception on the deserialization > side, because of a map size/entries mismatch on the serialization side caused > by the race described above. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-6842) Possible ClassCastException in HAEventWrapper during concurrent client registration and queue GII
Ryan McMahon created GEODE-6842: --- Summary: Possible ClassCastException in HAEventWrapper during concurrent client registration and queue GII Key: GEODE-6842 URL: https://issues.apache.org/jira/browse/GEODE-6842 Project: Geode Issue Type: Bug Components: client queues, client/server Reporter: Ryan McMahon It is possible for a ClassCastException to be thrown if a client is registering interest/CQ concurrently while a queue GII is being performed. The issue is that the queued event (HAEventWrapper) can be mutated by the client registration logic while it is in another client's queue, so if a GII occurs it could be serialized while being mutated. Specifically, the CqNameToOpHashMap was shown to throw the exception on the deserialization side, because of a map size/entries mismatch on the serialization side caused by the race described above. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-6839) CI Failure: JoinQueriesIntegrationTest.joiningThreeRegionsWithIndexesWhenIntermediateResultSizeIsHigherThanLimitClauseShouldNotTrimResults fails to match query result si
[
https://issues.apache.org/jira/browse/GEODE-6839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan José Ramos Cassella resolved GEODE-6839.
-
Resolution: Fixed
Fix Version/s: 1.10.0
> CI Failure:
> JoinQueriesIntegrationTest.joiningThreeRegionsWithIndexesWhenIntermediateResultSizeIsHigherThanLimitClauseShouldNotTrimResults
> fails to match query result size
> ---
>
> Key: GEODE-6839
> URL: https://issues.apache.org/jira/browse/GEODE-6839
> Project: Geode
> Issue Type: Bug
>Reporter: Juan José Ramos Cassella
>Assignee: Juan José Ramos Cassella
>Priority: Major
> Labels: GeodeCommons
> Fix For: 1.10.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> WindowsCoreIntegrationTestOpenJDK8 build 13:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsCoreIntegrationTestOpenJDK8/builds/13
> *Failure:*
> {noformat}
> org.apache.geode.cache.query.JoinQueriesIntegrationTest >
> joiningThreeRegionsWithIndexesWhenIntermediateResultSizeIsHigherThanLimitClauseShouldNotTrimResults
> - Using PDX: false FAILED
> org.junit.ComparisonFailure: expected:<[1]0> but was:<[]0>
> 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.cache.query.JoinQueriesIntegrationTest.joiningThreeRegionsWithIndexesWhenIntermediateResultSizeIsHigherThanLimitClauseShouldNotTrimResults(JoinQueriesIntegrationTest.java:378)
> {noformat}
> The failure can be reproduced locally by running {{./gradlew
> repeatIntegrationTest --no-parallel -Prepeat=100
> -PfailOnNoMatchingTests=false --tests
> org.apache.geode.cache.query.JoinQueriesIntegrationTest}}, it randomly fails
> *22%* of the time.
> Long story short: sometimes the query is executed *before* the actual index
> maintenance has finished and, as such, some entries are not included as part
> of the final result.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-6546) Geode-Native User Guide - document 'putgetremove' example
[ https://issues.apache.org/jira/browse/GEODE-6546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16858019#comment-16858019 ] ASF subversion and git services commented on GEODE-6546: Commit b3ed871a39943271e2314ac86c729519cf851f8f in geode-native's branch refs/heads/develop from Blake Bender [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=b3ed871 ] GEODE-6546: Fix doc comments for IRegion (#493) - Also remove unnecessary parameter to IRegion::Put call in PutGetRemove .net example > Geode-Native User Guide - document 'putgetremove' example > - > > Key: GEODE-6546 > URL: https://issues.apache.org/jira/browse/GEODE-6546 > Project: Geode > Issue Type: Sub-task > Components: docs, native client >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Major > Time Spent: 1h 50m > Remaining Estimate: 0h > > Document the 'putgetremove' example. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-6839) CI Failure: JoinQueriesIntegrationTest.joiningThreeRegionsWithIndexesWhenIntermediateResultSizeIsHigherThanLimitClauseShouldNotTrimResults fails to match query result s
[
https://issues.apache.org/jira/browse/GEODE-6839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16858018#comment-16858018
]
ASF subversion and git services commented on GEODE-6839:
Commit b09000f306d1b82df366b5a8bac203d188bfb680 in geode's branch
refs/heads/develop from Juan José Ramos
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=b09000f ]
GEODE-6839: Fix Flaky JoinQueriesIntegrationTest (#3678)
Index creation within the test is now done after region population
finishes, basically avoiding any race conditions that might arise
between adding entries to an index and query execution.
> CI Failure:
> JoinQueriesIntegrationTest.joiningThreeRegionsWithIndexesWhenIntermediateResultSizeIsHigherThanLimitClauseShouldNotTrimResults
> fails to match query result size
> ---
>
> Key: GEODE-6839
> URL: https://issues.apache.org/jira/browse/GEODE-6839
> Project: Geode
> Issue Type: Bug
>Reporter: Juan José Ramos Cassella
>Assignee: Juan José Ramos Cassella
>Priority: Major
> Labels: GeodeCommons
> Time Spent: 20m
> Remaining Estimate: 0h
>
> WindowsCoreIntegrationTestOpenJDK8 build 13:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsCoreIntegrationTestOpenJDK8/builds/13
> *Failure:*
> {noformat}
> org.apache.geode.cache.query.JoinQueriesIntegrationTest >
> joiningThreeRegionsWithIndexesWhenIntermediateResultSizeIsHigherThanLimitClauseShouldNotTrimResults
> - Using PDX: false FAILED
> org.junit.ComparisonFailure: expected:<[1]0> but was:<[]0>
> 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.cache.query.JoinQueriesIntegrationTest.joiningThreeRegionsWithIndexesWhenIntermediateResultSizeIsHigherThanLimitClauseShouldNotTrimResults(JoinQueriesIntegrationTest.java:378)
> {noformat}
> The failure can be reproduced locally by running {{./gradlew
> repeatIntegrationTest --no-parallel -Prepeat=100
> -PfailOnNoMatchingTests=false --tests
> org.apache.geode.cache.query.JoinQueriesIntegrationTest}}, it randomly fails
> *22%* of the time.
> Long story short: sometimes the query is executed *before* the actual index
> maintenance has finished and, as such, some entries are not included as part
> of the final result.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-6546) Geode-Native User Guide - document 'putgetremove' example
[ https://issues.apache.org/jira/browse/GEODE-6546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16858017#comment-16858017 ] ASF subversion and git services commented on GEODE-6546: Commit e309b575bd0f1f03e479b682cc6f0b532d3a8672 in geode-native's branch refs/heads/develop from Dave Barnes [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=e309b57 ] GEODE-6546: Geode-Native User Guide - document 'putgetremove' example (#491) > Geode-Native User Guide - document 'putgetremove' example > - > > Key: GEODE-6546 > URL: https://issues.apache.org/jira/browse/GEODE-6546 > Project: Geode > Issue Type: Sub-task > Components: docs, native client >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Major > Time Spent: 1h 40m > Remaining Estimate: 0h > > Document the 'putgetremove' example. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-6827) Benchmark CI: Make Windows jobs not gating for benchmarks
[ https://issues.apache.org/jira/browse/GEODE-6827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16857915#comment-16857915 ] ASF subversion and git services commented on GEODE-6827: Commit a023575c0309aa40d65ee195d3d68b98c338751c in geode's branch refs/heads/develop from Owen Nichols [ https://gitbox.apache.org/repos/asf?p=geode.git;h=a023575 ] GEODE-6827: Make JDK11 not gate for Benchmark > Benchmark CI: Make Windows jobs not gating for benchmarks > - > > Key: GEODE-6827 > URL: https://issues.apache.org/jira/browse/GEODE-6827 > Project: Geode > Issue Type: Improvement >Reporter: Helena Bales >Assignee: Helena Bales >Priority: Major > Labels: performance-benchmark > Time Spent: 1h 50m > Remaining Estimate: 0h > > In Geode CI, the Benchmark job is blocked by the successful completion of the > Windows tests. Since Benchmark runs on linux and the Windows tests still > frequently fail with timing issues, it does not make sense for these tests to > be gating to Benchmark runs. When they are gating, we do not get frequent > runs of the benchmark task. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-6576) DB connection rebalancing improvement
[ https://issues.apache.org/jira/browse/GEODE-6576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16857906#comment-16857906 ] ASF subversion and git services commented on GEODE-6576: Commit 5210670ca891729da78ead36dc1b63f49eced653 in geode-native's branch refs/heads/develop from mivanac [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=5210670 ] GEODE-6576: Improvements in cleanStaleConnections method (#477) Improvements in cleanStaleConnections method: - introduce phasing - return connections to pool as soon as possible This fault can be reproduced with geode-native-examples - putgetremove. For reproduction test: - set min and max connections to 800. - set LoadConditioningInterval to 60 secs - run continues get operation, and measure duration of get operation. - Every 60 seconds you will see peaks with time duration over 100ms.And this is the problem. > DB connection rebalancing improvement > - > > Key: GEODE-6576 > URL: https://issues.apache.org/jira/browse/GEODE-6576 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Mario Ivanac >Assignee: Mario Ivanac >Priority: Major > Labels: needs-review, pull-request-available > Fix For: 1.10.0 > > Time Spent: 1h 40m > Remaining Estimate: 0h > > When using min=max=120 connections, and about 2000 TPS it is observed, that > every 5 minutes (load-conditioning-interval) we get significant delays . But > I suspect you could reproduce it at any configuration, if you look for > increased delays when driver rebalances connections > (load-conditioning-interval). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-6827) Benchmark CI: Make Windows jobs not gating for benchmarks
[ https://issues.apache.org/jira/browse/GEODE-6827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16857904#comment-16857904 ] ASF subversion and git services commented on GEODE-6827: Commit d4fa160433a7ed8abc3fafd7924e7b1a84a0e49d in geode's branch refs/heads/develop from Helena Bales [ https://gitbox.apache.org/repos/asf?p=geode.git;h=d4fa160 ] GEODE-6827: Make windows not gate for Benchmark (#3668) * GEODE-6827: Make windows not gate for Benchmark Make the Windows tests not gating for Benchmark job, since benchmark is run on Linux. * change EXECUTE_TEST_TIMEOUT from lower to upper case * use a PLATFORM jinja variable > Benchmark CI: Make Windows jobs not gating for benchmarks > - > > Key: GEODE-6827 > URL: https://issues.apache.org/jira/browse/GEODE-6827 > Project: Geode > Issue Type: Improvement >Reporter: Helena Bales >Assignee: Helena Bales >Priority: Major > Labels: performance-benchmark > Time Spent: 1h 50m > Remaining Estimate: 0h > > In Geode CI, the Benchmark job is blocked by the successful completion of the > Windows tests. Since Benchmark runs on linux and the Windows tests still > frequently fail with timing issues, it does not make sense for these tests to > be gating to Benchmark runs. When they are gating, we do not get frequent > runs of the benchmark task. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-6827) Benchmark CI: Make Windows jobs not gating for benchmarks
[ https://issues.apache.org/jira/browse/GEODE-6827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16857903#comment-16857903 ] ASF subversion and git services commented on GEODE-6827: Commit d4fa160433a7ed8abc3fafd7924e7b1a84a0e49d in geode's branch refs/heads/develop from Helena Bales [ https://gitbox.apache.org/repos/asf?p=geode.git;h=d4fa160 ] GEODE-6827: Make windows not gate for Benchmark (#3668) * GEODE-6827: Make windows not gate for Benchmark Make the Windows tests not gating for Benchmark job, since benchmark is run on Linux. * change EXECUTE_TEST_TIMEOUT from lower to upper case * use a PLATFORM jinja variable > Benchmark CI: Make Windows jobs not gating for benchmarks > - > > Key: GEODE-6827 > URL: https://issues.apache.org/jira/browse/GEODE-6827 > Project: Geode > Issue Type: Improvement >Reporter: Helena Bales >Assignee: Helena Bales >Priority: Major > Labels: performance-benchmark > Time Spent: 1h 50m > Remaining Estimate: 0h > > In Geode CI, the Benchmark job is blocked by the successful completion of the > Windows tests. Since Benchmark runs on linux and the Windows tests still > frequently fail with timing issues, it does not make sense for these tests to > be gating to Benchmark runs. When they are gating, we do not get frequent > runs of the benchmark task. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-6841) Remove dependency on Attach API
Kirk Lund created GEODE-6841: Summary: Remove dependency on Attach API Key: GEODE-6841 URL: https://issues.apache.org/jira/browse/GEODE-6841 Project: Geode Issue Type: Wish Components: gfsh Reporter: Kirk Lund Grep Geode code for "com.sun.tools.attach" and remove all uses of the Attach API. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-6840) Update to ACE 6.5.5, google/benchmarks 1.5.0, SQLite 3.28.0
[ https://issues.apache.org/jira/browse/GEODE-6840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacob S. Barrett updated GEODE-6840: Summary: Update to ACE 6.5.5, google/benchmarks 1.5.0, SQLite 3.28.0 (was: Update to ACE 6.5.5, google/benchmarks 1.5.0) > Update to ACE 6.5.5, google/benchmarks 1.5.0, SQLite 3.28.0 > --- > > Key: GEODE-6840 > URL: https://issues.apache.org/jira/browse/GEODE-6840 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Jacob S. Barrett >Assignee: Jacob S. Barrett >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-6840) Update to ACE 6.5.5, google/benchmarks 1.5.0
[ https://issues.apache.org/jira/browse/GEODE-6840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacob S. Barrett updated GEODE-6840: Summary: Update to ACE 6.5.5, google/benchmarks 1.5.0 (was: Update to ACE 6.5.5) > Update to ACE 6.5.5, google/benchmarks 1.5.0 > > > Key: GEODE-6840 > URL: https://issues.apache.org/jira/browse/GEODE-6840 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Jacob S. Barrett >Assignee: Jacob S. Barrett >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-6840) Update to ACE 6.5.5
Jacob S. Barrett created GEODE-6840: --- Summary: Update to ACE 6.5.5 Key: GEODE-6840 URL: https://issues.apache.org/jira/browse/GEODE-6840 Project: Geode Issue Type: Improvement Components: native client Reporter: Jacob S. Barrett -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-6840) Update to ACE 6.5.5
[ https://issues.apache.org/jira/browse/GEODE-6840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacob S. Barrett reassigned GEODE-6840: --- Assignee: Jacob S. Barrett > Update to ACE 6.5.5 > --- > > Key: GEODE-6840 > URL: https://issues.apache.org/jira/browse/GEODE-6840 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Jacob S. Barrett >Assignee: Jacob S. Barrett >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-6839) CI Failure: JoinQueriesIntegrationTest.joiningThreeRegionsWithIndexesWhenIntermediateResultSizeIsHigherThanLimitClauseShouldNotTrimResults fails to match query result siz
[
https://issues.apache.org/jira/browse/GEODE-6839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan José Ramos Cassella updated GEODE-6839:
Labels: GeodeCommons (was: )
> CI Failure:
> JoinQueriesIntegrationTest.joiningThreeRegionsWithIndexesWhenIntermediateResultSizeIsHigherThanLimitClauseShouldNotTrimResults
> fails to match query result size
> ---
>
> Key: GEODE-6839
> URL: https://issues.apache.org/jira/browse/GEODE-6839
> Project: Geode
> Issue Type: Bug
>Reporter: Juan José Ramos Cassella
>Assignee: Juan José Ramos Cassella
>Priority: Major
> Labels: GeodeCommons
>
> WindowsCoreIntegrationTestOpenJDK8 build 13:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsCoreIntegrationTestOpenJDK8/builds/13
> *Failure:*
> {noformat}
> org.apache.geode.cache.query.JoinQueriesIntegrationTest >
> joiningThreeRegionsWithIndexesWhenIntermediateResultSizeIsHigherThanLimitClauseShouldNotTrimResults
> - Using PDX: false FAILED
> org.junit.ComparisonFailure: expected:<[1]0> but was:<[]0>
> 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.cache.query.JoinQueriesIntegrationTest.joiningThreeRegionsWithIndexesWhenIntermediateResultSizeIsHigherThanLimitClauseShouldNotTrimResults(JoinQueriesIntegrationTest.java:378)
> {noformat}
> The failure can be reproduced locally by running {{./gradlew
> repeatIntegrationTest --no-parallel -Prepeat=100
> -PfailOnNoMatchingTests=false --tests
> org.apache.geode.cache.query.JoinQueriesIntegrationTest}}, it randomly fails
> *22%* of the time.
> Long story short: sometimes the query is executed *before* the actual index
> maintenance has finished and, as such, some entries are not included as part
> of the final result.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-6839) CI Failure: JoinQueriesIntegrationTest.joiningThreeRegionsWithIndexesWhenIntermediateResultSizeIsHigherThanLimitClauseShouldNotTrimResults fails to match query result siz
Juan José Ramos Cassella created GEODE-6839:
---
Summary: CI Failure:
JoinQueriesIntegrationTest.joiningThreeRegionsWithIndexesWhenIntermediateResultSizeIsHigherThanLimitClauseShouldNotTrimResults
fails to match query result size
Key: GEODE-6839
URL: https://issues.apache.org/jira/browse/GEODE-6839
Project: Geode
Issue Type: Bug
Reporter: Juan José Ramos Cassella
WindowsCoreIntegrationTestOpenJDK8 build 13:
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsCoreIntegrationTestOpenJDK8/builds/13
*Failure:*
{noformat}
org.apache.geode.cache.query.JoinQueriesIntegrationTest >
joiningThreeRegionsWithIndexesWhenIntermediateResultSizeIsHigherThanLimitClauseShouldNotTrimResults
- Using PDX: false FAILED
org.junit.ComparisonFailure: expected:<[1]0> but was:<[]0>
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.cache.query.JoinQueriesIntegrationTest.joiningThreeRegionsWithIndexesWhenIntermediateResultSizeIsHigherThanLimitClauseShouldNotTrimResults(JoinQueriesIntegrationTest.java:378)
{noformat}
The failure can be reproduced locally by running {{./gradlew
repeatIntegrationTest --no-parallel -Prepeat=100 -PfailOnNoMatchingTests=false
--tests org.apache.geode.cache.query.JoinQueriesIntegrationTest}}, it randomly
fails *22%* of the time.
Long story short: sometimes the query is executed *before* the actual index
maintenance has finished and, as such, some entries are not included as part of
the final result.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-6839) CI Failure: JoinQueriesIntegrationTest.joiningThreeRegionsWithIndexesWhenIntermediateResultSizeIsHigherThanLimitClauseShouldNotTrimResults fails to match query result si
[
https://issues.apache.org/jira/browse/GEODE-6839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan José Ramos Cassella reassigned GEODE-6839:
---
Assignee: Juan José Ramos Cassella
> CI Failure:
> JoinQueriesIntegrationTest.joiningThreeRegionsWithIndexesWhenIntermediateResultSizeIsHigherThanLimitClauseShouldNotTrimResults
> fails to match query result size
> ---
>
> Key: GEODE-6839
> URL: https://issues.apache.org/jira/browse/GEODE-6839
> Project: Geode
> Issue Type: Bug
>Reporter: Juan José Ramos Cassella
>Assignee: Juan José Ramos Cassella
>Priority: Major
>
> WindowsCoreIntegrationTestOpenJDK8 build 13:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsCoreIntegrationTestOpenJDK8/builds/13
> *Failure:*
> {noformat}
> org.apache.geode.cache.query.JoinQueriesIntegrationTest >
> joiningThreeRegionsWithIndexesWhenIntermediateResultSizeIsHigherThanLimitClauseShouldNotTrimResults
> - Using PDX: false FAILED
> org.junit.ComparisonFailure: expected:<[1]0> but was:<[]0>
> 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.cache.query.JoinQueriesIntegrationTest.joiningThreeRegionsWithIndexesWhenIntermediateResultSizeIsHigherThanLimitClauseShouldNotTrimResults(JoinQueriesIntegrationTest.java:378)
> {noformat}
> The failure can be reproduced locally by running {{./gradlew
> repeatIntegrationTest --no-parallel -Prepeat=100
> -PfailOnNoMatchingTests=false --tests
> org.apache.geode.cache.query.JoinQueriesIntegrationTest}}, it randomly fails
> *22%* of the time.
> Long story short: sometimes the query is executed *before* the actual index
> maintenance has finished and, as such, some entries are not included as part
> of the final result.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-6806) Wrong Results in multi OQL joins + Indexes + LIMIT clause
[
https://issues.apache.org/jira/browse/GEODE-6806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan José Ramos Cassella resolved GEODE-6806.
-
Resolution: Fixed
> Wrong Results in multi OQL joins + Indexes + LIMIT clause
> -
>
> Key: GEODE-6806
> URL: https://issues.apache.org/jira/browse/GEODE-6806
> Project: Geode
> Issue Type: Bug
> Components: querying
>Reporter: Juan José Ramos Cassella
>Assignee: Juan José Ramos Cassella
>Priority: Major
> Labels: GeodeCommons
> Fix For: 1.10.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> When joining multiple regions with indexes defined on them, the results of
> the query might be wrong if the {{LIMIT}} keyword is used in the {{OQL}} and
> the intermediate result size of the query is greater than the actual
> {{LIMIT}} used.
> Internally we get the _partial_ results from the {{indexes}} and _cut down_
> these intermediate results during the actual execution. With the goal of
> speeding things up, we use the {{LIMIT}} value to stop the iteration sooner
> but we do not know if the first X results (governed by the {{LIMIT}} value)
> might or might not fulfil the rest of the operands.
> The {{LIMIT}} clause is _disabled_ at the {{index}} level but still enabled
> in this intermediate step, which is causing the final result to not contain
> certain rows that should be included.
> The following example reproduces the issue (doesn't matter whether {{PDX}} is
> used or not):
> {code:java}
> private void populateTripleJointRegions(int expectedMatches, int
> extraEntitiesPerRegion, Cache cache, Region orderRegion,
> Region validationIssueRegion, Region
> validationIssueXRefRegion) {
> for (int i = 0; i < expectedMatches; i++) {
> PdxInstance orderPdx = cache
> .createPdxInstanceFactory("org.apache.geode.test.Order")
> .writeString("orderId", "orderId_" + i)
> .writeInt("version", i)
> .create();
> PdxInstance validationIssuePdx = cache
> .createPdxInstanceFactory("org.apache.geode.test.ValidationIssue")
> .writeString("issueId", "issueId_" + i)
> .writeDate("createdTime", Calendar.getInstance().getTime())
> .create();
> PdxInstance validationIssueXRefPdx = cache
>
> .createPdxInstanceFactory("org.apache.geode.test.OrderValidationIssueXRef")
> .writeString("validationIssueXRefID", "validationIssueXRefID_" + i)
> .writeString("referenceIssueId", "issueId_" + i)
> .writeString("referenceOrderId", "orderId_" + i)
> .writeInt("referenceOrderVersion", i)
> .create();
> orderRegion.put("orderId_" + i, orderPdx);
> validationIssueRegion.put("issueId_" + i , validationIssuePdx);
> validationIssueXRefRegion.put("validationIssueXRefID_" + i,
> validationIssueXRefPdx);
> }
> for (int i = 0; i < extraEntitiesPerRegion; i++) {
> PdxInstance orderPdx = cache
> .createPdxInstanceFactory("org.apache.geode.test.Order")
> .writeString("orderId", "orderId#" + i)
> .writeInt("version", i)
> .create();
> PdxInstance validationIssuePdx = cache
> .createPdxInstanceFactory("org.apache.geode.test.ValidationIssue")
> .writeString("referenceIssueId", "referenceIssueId#" + i)
> .writeDate("createdTime", Calendar.getInstance().getTime())
> .create();
> PdxInstance validationIssueXRefPdx = cache
>
> .createPdxInstanceFactory("org.apache.geode.test.OrderValidationIssueXRef")
> .writeString("validationIssueXRefID", "validationIssueXRefID#" + i)
> .writeString("referenceIssueId", "validationIssueID2#" + i)
> .writeString("referenceOrderId", "orderId#2" + i)
> .writeInt("referenceOrderVersion", i)
> .create();
> orderRegion.put("orderId#" + i, orderPdx);
> validationIssueRegion.put("issueId#" + i , validationIssuePdx );
> validationIssueXRefRegion.put("validationIssueXRefID#" + i,
> validationIssueXRefPdx);
> }
> }
> @Test
> public void
> joiningThreeRegionsWhenIntermediateResultSizeIsHigherThanLimitClauseShouldNotTrimResults()
> throws Exception {
> int matches = 10;
> int extraEntitiesPerRegion = 25;
> Cache cache = CacheUtils.getCache();
> QueryService queryService = cache.getQueryService();
> String queryString = "SELECT issue.issueId, issue.createdTime, o.orderId,
> o.version "
> + "FROM /ValidationIssue issue, /OrderValidationIssueXRef xRef,
> /Order o "
> + "WHERE "
> + "issue.issueId = xRef.referenceIssueId "
> + "AND "
> + "xRef.referenceOrderId = o.orderId "
> + "AND "
>
[jira] [Commented] (GEODE-6806) Wrong Results in multi OQL joins + Indexes + LIMIT clause
[
https://issues.apache.org/jira/browse/GEODE-6806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16857836#comment-16857836
]
Juan José Ramos Cassella commented on GEODE-6806:
-
Discard my last comment, the changes actually fixed the issue just fine. The
failures in CI are caused by the flaky test that I've introduced when
developing the fix: sometimes the query is executed before the index
maintenance has finished and, as such, some entries are not included into the
result. Will open a new JIRA to address that problem.
> Wrong Results in multi OQL joins + Indexes + LIMIT clause
> -
>
> Key: GEODE-6806
> URL: https://issues.apache.org/jira/browse/GEODE-6806
> Project: Geode
> Issue Type: Bug
> Components: querying
>Reporter: Juan José Ramos Cassella
>Assignee: Juan José Ramos Cassella
>Priority: Major
> Labels: GeodeCommons
> Fix For: 1.10.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> When joining multiple regions with indexes defined on them, the results of
> the query might be wrong if the {{LIMIT}} keyword is used in the {{OQL}} and
> the intermediate result size of the query is greater than the actual
> {{LIMIT}} used.
> Internally we get the _partial_ results from the {{indexes}} and _cut down_
> these intermediate results during the actual execution. With the goal of
> speeding things up, we use the {{LIMIT}} value to stop the iteration sooner
> but we do not know if the first X results (governed by the {{LIMIT}} value)
> might or might not fulfil the rest of the operands.
> The {{LIMIT}} clause is _disabled_ at the {{index}} level but still enabled
> in this intermediate step, which is causing the final result to not contain
> certain rows that should be included.
> The following example reproduces the issue (doesn't matter whether {{PDX}} is
> used or not):
> {code:java}
> private void populateTripleJointRegions(int expectedMatches, int
> extraEntitiesPerRegion, Cache cache, Region orderRegion,
> Region validationIssueRegion, Region
> validationIssueXRefRegion) {
> for (int i = 0; i < expectedMatches; i++) {
> PdxInstance orderPdx = cache
> .createPdxInstanceFactory("org.apache.geode.test.Order")
> .writeString("orderId", "orderId_" + i)
> .writeInt("version", i)
> .create();
> PdxInstance validationIssuePdx = cache
> .createPdxInstanceFactory("org.apache.geode.test.ValidationIssue")
> .writeString("issueId", "issueId_" + i)
> .writeDate("createdTime", Calendar.getInstance().getTime())
> .create();
> PdxInstance validationIssueXRefPdx = cache
>
> .createPdxInstanceFactory("org.apache.geode.test.OrderValidationIssueXRef")
> .writeString("validationIssueXRefID", "validationIssueXRefID_" + i)
> .writeString("referenceIssueId", "issueId_" + i)
> .writeString("referenceOrderId", "orderId_" + i)
> .writeInt("referenceOrderVersion", i)
> .create();
> orderRegion.put("orderId_" + i, orderPdx);
> validationIssueRegion.put("issueId_" + i , validationIssuePdx);
> validationIssueXRefRegion.put("validationIssueXRefID_" + i,
> validationIssueXRefPdx);
> }
> for (int i = 0; i < extraEntitiesPerRegion; i++) {
> PdxInstance orderPdx = cache
> .createPdxInstanceFactory("org.apache.geode.test.Order")
> .writeString("orderId", "orderId#" + i)
> .writeInt("version", i)
> .create();
> PdxInstance validationIssuePdx = cache
> .createPdxInstanceFactory("org.apache.geode.test.ValidationIssue")
> .writeString("referenceIssueId", "referenceIssueId#" + i)
> .writeDate("createdTime", Calendar.getInstance().getTime())
> .create();
> PdxInstance validationIssueXRefPdx = cache
>
> .createPdxInstanceFactory("org.apache.geode.test.OrderValidationIssueXRef")
> .writeString("validationIssueXRefID", "validationIssueXRefID#" + i)
> .writeString("referenceIssueId", "validationIssueID2#" + i)
> .writeString("referenceOrderId", "orderId#2" + i)
> .writeInt("referenceOrderVersion", i)
> .create();
> orderRegion.put("orderId#" + i, orderPdx);
> validationIssueRegion.put("issueId#" + i , validationIssuePdx );
> validationIssueXRefRegion.put("validationIssueXRefID#" + i,
> validationIssueXRefPdx);
> }
> }
> @Test
> public void
> joiningThreeRegionsWhenIntermediateResultSizeIsHigherThanLimitClauseShouldNotTrimResults()
> throws Exception {
> int matches = 10;
> int extraEntitiesPerRegion = 25;
> Cache cache = CacheUtils.getCache();
> QueryService queryService =
[jira] [Assigned] (GEODE-6838) ConnectionImpl.getClientFunctionTimeout reads a system property every time it is called
[ https://issues.apache.org/jira/browse/GEODE-6838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Ivanac reassigned GEODE-6838: --- Assignee: Mario Ivanac > ConnectionImpl.getClientFunctionTimeout reads a system property every time it > is called > --- > > Key: GEODE-6838 > URL: https://issues.apache.org/jira/browse/GEODE-6838 > Project: Geode > Issue Type: Improvement > Components: core >Reporter: Darrel Schneider >Assignee: Mario Ivanac >Priority: Major > Labels: performance > > ConnectionImpl.getClientFunctionTimeout reads a system property every time it > is called. This can impact concurrent function executions since reading the > system property hits a synchronized HashTable -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-6821) Multiple Serial GatewaySenders that are primary in different members can cause a distributed deadlock
[ https://issues.apache.org/jira/browse/GEODE-6821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Barry Oglesby resolved GEODE-6821. -- Resolution: Fixed Fix Version/s: 1.10.0 > Multiple Serial GatewaySenders that are primary in different members can > cause a distributed deadlock > - > > Key: GEODE-6821 > URL: https://issues.apache.org/jira/browse/GEODE-6821 > Project: Geode > Issue Type: Bug > Components: messaging, wan >Reporter: Barry Oglesby >Assignee: Barry Oglesby >Priority: Major > Fix For: 1.10.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > A test with this scenario causes a distributed deadlock. > 3 servers each with: > - a function that performs a random region operation on the input region > - a replicated region on which the function is executed > - two regions each with a serial AEQ (the type of region could be either > replicate or partitioned) > 1 multi-threaded client that repeatedly executes the function with random > region names and operations. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
