[jira] [Updated] (GEODE-5648) Native Client docs: Add a page describing Continuous Queries
[ https://issues.apache.org/jira/browse/GEODE-5648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-5648: -- Labels: pull-request-available (was: ) > Native Client docs: Add a page describing Continuous Queries > > > Key: GEODE-5648 > URL: https://issues.apache.org/jira/browse/GEODE-5648 > Project: Geode > Issue Type: New Feature > Components: docs >Reporter: Dave Barnes >Priority: Major > Labels: pull-request-available > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-5648) Native Client docs: Add a page describing Continuous Queries
Dave Barnes created GEODE-5648: -- Summary: Native Client docs: Add a page describing Continuous Queries Key: GEODE-5648 URL: https://issues.apache.org/jira/browse/GEODE-5648 Project: Geode Issue Type: New Feature Components: docs Reporter: Dave Barnes -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5646) Client throws ToDataException when locator is shutting down
[
https://issues.apache.org/jira/browse/GEODE-5646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16594289#comment-16594289
]
ASF subversion and git services commented on GEODE-5646:
Commit 3651a9a9b3819948da18e02b7fc64c3493f6d886 in geode's branch
refs/heads/develop from [~bschuchardt]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=3651a9a ]
GEODE-5646 Client throws ToDataException when locator is shutting down
Catch and handle ToDataException. Reviewed by mhanson
> Client throws ToDataException when locator is shutting down
> ---
>
> Key: GEODE-5646
> URL: https://issues.apache.org/jira/browse/GEODE-5646
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Reporter: Bruce Schuchardt
>Assignee: Bruce Schuchardt
>Priority: Major
> Fix For: 1.8.0
>
>
> This hasn't been seen in Geode but in an older version of Pivotal GemFire.
> The code in question hasn't changed so we ought to fix it.
> {noformat}
> ERROR util.TestException: doEntryOperations caught Exception
> com.gemstone.gemfire.ToDataException: toData failed on DataSerializable class
> com.gemstone.gemfire.distributed.internal.ServerLocation
> at
> com.gemstone.gemfire.internal.InternalDataSerializer.invokeToData(InternalDataSerializer.java:2424)
> at
> com.gemstone.gemfire.cache.client.internal.locator.SerializationHelper.writeServerLocations(SerializationHelper.java:39)
> at
> com.gemstone.gemfire.cache.client.internal.locator.SerializationHelper.writeServerLocationSet(SerializationHelper.java:75)
> at
> com.gemstone.gemfire.cache.client.internal.locator.ClientConnectionRequest.toData(ClientConnectionRequest.java:44)
> at
> com.gemstone.gemfire.internal.InternalDataSerializer.invokeToData(InternalDataSerializer.java:2411)
> at
> com.gemstone.gemfire.internal.InternalDataSerializer.writeDSFID(InternalDataSerializer.java:1382)
> at
> com.gemstone.gemfire.internal.InternalDataSerializer.basicWriteObject(InternalDataSerializer.java:2156)
> at
> com.gemstone.gemfire.DataSerializer.writeObject(DataSerializer.java:3181)
> at
> com.gemstone.org.jgroups.stack.tcpserver.TcpClient.requestToServer(TcpClient.java:115)
> at
> com.gemstone.org.jgroups.stack.tcpserver.TcpClient.requestToServer(TcpClient.java:78)
> at
> com.gemstone.gemfire.cache.client.internal.AutoConnectionSourceImpl.queryOneLocator(AutoConnectionSourceImpl.java:188)
> at
> com.gemstone.gemfire.cache.client.internal.AutoConnectionSourceImpl.queryLocators(AutoConnectionSourceImpl.java:220)
> at
> com.gemstone.gemfire.cache.client.internal.AutoConnectionSourceImpl.findServer(AutoConnectionSourceImpl.java:132)
> at
> com.gemstone.gemfire.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:227)
> at
> com.gemstone.gemfire.cache.client.internal.pooling.ConnectionManagerImpl.exchangeConnection(ConnectionManagerImpl.java:421)
> at
> com.gemstone.gemfire.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:173)
> at
> com.gemstone.gemfire.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:115)
> at
> com.gemstone.gemfire.cache.client.internal.PoolImpl.execute(PoolImpl.java:702)
> at
> com.gemstone.gemfire.cache.client.internal.KeySetOp.execute(KeySetOp.java:38)
> at
> com.gemstone.gemfire.cache.client.internal.ServerRegionProxy.keySet(ServerRegionProxy.java:348)
> at
> com.gemstone.gemfire.internal.cache.LocalRegion.keySetOnServer(LocalRegion.java:4159)
> {noformat}
> The client is trying to serialize ServerLocation objects and send them to a
> locator. AutoConnectionSourceImpl.queryOneLocator() has code to handle
> IOException and report the locator as being down but since ServerLocation
> isn't a DataSerializableFixedID instance the serialization code throws a
> ToDataException instead of an IOException. Adding ToDataException handling to
> queryOneLocator() should fix the problem.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-5646) Client throws ToDataException when locator is shutting down
[
https://issues.apache.org/jira/browse/GEODE-5646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruce Schuchardt resolved GEODE-5646.
-
Resolution: Fixed
Fix Version/s: 1.8.0
> Client throws ToDataException when locator is shutting down
> ---
>
> Key: GEODE-5646
> URL: https://issues.apache.org/jira/browse/GEODE-5646
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Reporter: Bruce Schuchardt
>Assignee: Bruce Schuchardt
>Priority: Major
> Fix For: 1.8.0
>
>
> This hasn't been seen in Geode but in an older version of Pivotal GemFire.
> The code in question hasn't changed so we ought to fix it.
> {noformat}
> ERROR util.TestException: doEntryOperations caught Exception
> com.gemstone.gemfire.ToDataException: toData failed on DataSerializable class
> com.gemstone.gemfire.distributed.internal.ServerLocation
> at
> com.gemstone.gemfire.internal.InternalDataSerializer.invokeToData(InternalDataSerializer.java:2424)
> at
> com.gemstone.gemfire.cache.client.internal.locator.SerializationHelper.writeServerLocations(SerializationHelper.java:39)
> at
> com.gemstone.gemfire.cache.client.internal.locator.SerializationHelper.writeServerLocationSet(SerializationHelper.java:75)
> at
> com.gemstone.gemfire.cache.client.internal.locator.ClientConnectionRequest.toData(ClientConnectionRequest.java:44)
> at
> com.gemstone.gemfire.internal.InternalDataSerializer.invokeToData(InternalDataSerializer.java:2411)
> at
> com.gemstone.gemfire.internal.InternalDataSerializer.writeDSFID(InternalDataSerializer.java:1382)
> at
> com.gemstone.gemfire.internal.InternalDataSerializer.basicWriteObject(InternalDataSerializer.java:2156)
> at
> com.gemstone.gemfire.DataSerializer.writeObject(DataSerializer.java:3181)
> at
> com.gemstone.org.jgroups.stack.tcpserver.TcpClient.requestToServer(TcpClient.java:115)
> at
> com.gemstone.org.jgroups.stack.tcpserver.TcpClient.requestToServer(TcpClient.java:78)
> at
> com.gemstone.gemfire.cache.client.internal.AutoConnectionSourceImpl.queryOneLocator(AutoConnectionSourceImpl.java:188)
> at
> com.gemstone.gemfire.cache.client.internal.AutoConnectionSourceImpl.queryLocators(AutoConnectionSourceImpl.java:220)
> at
> com.gemstone.gemfire.cache.client.internal.AutoConnectionSourceImpl.findServer(AutoConnectionSourceImpl.java:132)
> at
> com.gemstone.gemfire.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:227)
> at
> com.gemstone.gemfire.cache.client.internal.pooling.ConnectionManagerImpl.exchangeConnection(ConnectionManagerImpl.java:421)
> at
> com.gemstone.gemfire.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:173)
> at
> com.gemstone.gemfire.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:115)
> at
> com.gemstone.gemfire.cache.client.internal.PoolImpl.execute(PoolImpl.java:702)
> at
> com.gemstone.gemfire.cache.client.internal.KeySetOp.execute(KeySetOp.java:38)
> at
> com.gemstone.gemfire.cache.client.internal.ServerRegionProxy.keySet(ServerRegionProxy.java:348)
> at
> com.gemstone.gemfire.internal.cache.LocalRegion.keySetOnServer(LocalRegion.java:4159)
> {noformat}
> The client is trying to serialize ServerLocation objects and send them to a
> locator. AutoConnectionSourceImpl.queryOneLocator() has code to handle
> IOException and report the locator as being down but since ServerLocation
> isn't a DataSerializableFixedID instance the serialization code throws a
> ToDataException instead of an IOException. Adding ToDataException handling to
> queryOneLocator() should fix the problem.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-5313) User Guide - consolidate transaction coding examples
[ https://issues.apache.org/jira/browse/GEODE-5313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Barnes resolved GEODE-5313. Resolution: Fixed Fix Version/s: 1.7.0 > User Guide - consolidate transaction coding examples > > > Key: GEODE-5313 > URL: https://issues.apache.org/jira/browse/GEODE-5313 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Major > Labels: pull-request-available > Fix For: 1.7.0 > > Time Spent: 20m > Remaining Estimate: 0h > > The examples are short, but currently housed in separate files. > Merge into a single file, simplify left-hand nav. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-5308) User Guide - simplify terminology: "cache transactions" can be "transactions"
[ https://issues.apache.org/jira/browse/GEODE-5308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Barnes resolved GEODE-5308. Resolution: Fixed Fix Version/s: 1.7.0 > User Guide - simplify terminology: "cache transactions" can be "transactions" > - > > Key: GEODE-5308 > URL: https://issues.apache.org/jira/browse/GEODE-5308 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Major > Labels: pull-request-available > Fix For: 1.7.0 > > Time Spent: 1h > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-5647) MultiVMRegionTestCase::waitForAsyncProcessing is not a well designed function
Mark Hanson created GEODE-5647: -- Summary: MultiVMRegionTestCase::waitForAsyncProcessing is not a well designed function Key: GEODE-5647 URL: https://issues.apache.org/jira/browse/GEODE-5647 Project: Geode Issue Type: Task Components: tests Reporter: Mark Hanson The logic of the method is confusing and it may be misused in several places. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-5646) Client throws ToDataException when locator is shutting down
[
https://issues.apache.org/jira/browse/GEODE-5646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruce Schuchardt reassigned GEODE-5646:
---
Assignee: Bruce Schuchardt
> Client throws ToDataException when locator is shutting down
> ---
>
> Key: GEODE-5646
> URL: https://issues.apache.org/jira/browse/GEODE-5646
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Reporter: Bruce Schuchardt
>Assignee: Bruce Schuchardt
>Priority: Major
>
> This hasn't been seen in Geode but in an older version of Pivotal GemFire.
> The code in question hasn't changed so we ought to fix it.
> {noformat}
> ERROR util.TestException: doEntryOperations caught Exception
> com.gemstone.gemfire.ToDataException: toData failed on DataSerializable class
> com.gemstone.gemfire.distributed.internal.ServerLocation
> at
> com.gemstone.gemfire.internal.InternalDataSerializer.invokeToData(InternalDataSerializer.java:2424)
> at
> com.gemstone.gemfire.cache.client.internal.locator.SerializationHelper.writeServerLocations(SerializationHelper.java:39)
> at
> com.gemstone.gemfire.cache.client.internal.locator.SerializationHelper.writeServerLocationSet(SerializationHelper.java:75)
> at
> com.gemstone.gemfire.cache.client.internal.locator.ClientConnectionRequest.toData(ClientConnectionRequest.java:44)
> at
> com.gemstone.gemfire.internal.InternalDataSerializer.invokeToData(InternalDataSerializer.java:2411)
> at
> com.gemstone.gemfire.internal.InternalDataSerializer.writeDSFID(InternalDataSerializer.java:1382)
> at
> com.gemstone.gemfire.internal.InternalDataSerializer.basicWriteObject(InternalDataSerializer.java:2156)
> at
> com.gemstone.gemfire.DataSerializer.writeObject(DataSerializer.java:3181)
> at
> com.gemstone.org.jgroups.stack.tcpserver.TcpClient.requestToServer(TcpClient.java:115)
> at
> com.gemstone.org.jgroups.stack.tcpserver.TcpClient.requestToServer(TcpClient.java:78)
> at
> com.gemstone.gemfire.cache.client.internal.AutoConnectionSourceImpl.queryOneLocator(AutoConnectionSourceImpl.java:188)
> at
> com.gemstone.gemfire.cache.client.internal.AutoConnectionSourceImpl.queryLocators(AutoConnectionSourceImpl.java:220)
> at
> com.gemstone.gemfire.cache.client.internal.AutoConnectionSourceImpl.findServer(AutoConnectionSourceImpl.java:132)
> at
> com.gemstone.gemfire.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:227)
> at
> com.gemstone.gemfire.cache.client.internal.pooling.ConnectionManagerImpl.exchangeConnection(ConnectionManagerImpl.java:421)
> at
> com.gemstone.gemfire.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:173)
> at
> com.gemstone.gemfire.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:115)
> at
> com.gemstone.gemfire.cache.client.internal.PoolImpl.execute(PoolImpl.java:702)
> at
> com.gemstone.gemfire.cache.client.internal.KeySetOp.execute(KeySetOp.java:38)
> at
> com.gemstone.gemfire.cache.client.internal.ServerRegionProxy.keySet(ServerRegionProxy.java:348)
> at
> com.gemstone.gemfire.internal.cache.LocalRegion.keySetOnServer(LocalRegion.java:4159)
> {noformat}
> The client is trying to serialize ServerLocation objects and send them to a
> locator. AutoConnectionSourceImpl.queryOneLocator() has code to handle
> IOException and report the locator as being down but since ServerLocation
> isn't a DataSerializableFixedID instance the serialization code throws a
> ToDataException instead of an IOException. Adding ToDataException handling to
> queryOneLocator() should fix the problem.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5642) cleanAll task is no longer necessary
[ https://issues.apache.org/jira/browse/GEODE-5642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16594262#comment-16594262 ] ASF subversion and git services commented on GEODE-5642: Commit 48fe306dcb699f64c15f8e8faba6fc2246ee45d1 in geode's branch refs/heads/develop from FSOUTHERLAND [ https://gitbox.apache.org/repos/asf?p=geode.git;h=48fe306 ] GEODE-5642 remove gradle task :cleanAll (#2385) Co-authored-by: Finn Southerland > cleanAll task is no longer necessary > > > Key: GEODE-5642 > URL: https://issues.apache.org/jira/browse/GEODE-5642 > Project: Geode > Issue Type: Task > Components: build >Reporter: Finn Southerland >Priority: Major > Labels: pull-request-available > Time Spent: 40m > Remaining Estimate: 0h > > Because the project structure has changed, we no longer need a custom > 'cleanAll' task to delete the root build directory. We should remove it. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5402) Disk recovery sometimes hangs when no member is recognized as having the most recent data
[ https://issues.apache.org/jira/browse/GEODE-5402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-5402: - Fix Version/s: 1.7.0 > Disk recovery sometimes hangs when no member is recognized as having the most > recent data > -- > > Key: GEODE-5402 > URL: https://issues.apache.org/jira/browse/GEODE-5402 > Project: Geode > Issue Type: Bug > Components: persistence >Reporter: Lynn Gallinat >Assignee: Lynn Gallinat >Priority: Major > Fix For: 1.7.0 > > > During disk recovery, sometimes a the system will hang because every member > is waiting for others to initialize first, and nobody is recognized as having > the most recent data. > This can happen when a member persists its most recent view of another member > to disk, then that member is killed before it can remove the older view of > the other member from the op log files. When starting the cluster from disk, > the member then has two views of the other member, one recent and the other > stale. The member then decides is needs to wait for the stale view of the > other member which causes the hang. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5359) Infinite loop when a thread is interrupting during messaging
[
https://issues.apache.org/jira/browse/GEODE-5359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16594255#comment-16594255
]
Alexander Murmann commented on GEODE-5359:
--
[~upthewaterspout] Since we are having a discussion on the dev list about 1.7
and this happened since the last release, I am marking this as fixed in 1.7.
Please correct this and let me know I screwed up if I did.
> Infinite loop when a thread is interrupting during messaging
>
>
> Key: GEODE-5359
> URL: https://issues.apache.org/jira/browse/GEODE-5359
> Project: Geode
> Issue Type: Bug
> Components: messaging
>Reporter: Dan Smith
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.7.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> This is similar to GEODE-5358, but it has a much easier fix. If a thread is
> interrupted while sending a message, it can get into an infinite loop because
> we keep reinterrupting the same thread and never clear the interrupt bit. The
> culprit is this line in DirectChannel.sendToMany
>
> {noformat}
> interrupted = interrupted || Thread.interrupted();{noformat}
> The issue is that if interrupted is already true, this won't call
> Thread.interrupted and clear the interrupt bit.
> The test checked into GEODE-5358 will reproduce this, but that can't be
> included with this fix because it still hangs due to GEODE-5358.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5402) Disk recovery sometimes hangs when no member is recognized as having the most recent data
[ https://issues.apache.org/jira/browse/GEODE-5402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16594253#comment-16594253 ] Alexander Murmann commented on GEODE-5402: -- [~lgallinat] Since we are having a discussion on the dev list about 1.7 and this happened since the last release, I am marking this as fixed in 1.7. Please correct this and let me know I screwed up if I did. > Disk recovery sometimes hangs when no member is recognized as having the most > recent data > -- > > Key: GEODE-5402 > URL: https://issues.apache.org/jira/browse/GEODE-5402 > Project: Geode > Issue Type: Bug > Components: persistence >Reporter: Lynn Gallinat >Assignee: Lynn Gallinat >Priority: Major > Fix For: 1.7.0 > > > During disk recovery, sometimes a the system will hang because every member > is waiting for others to initialize first, and nobody is recognized as having > the most recent data. > This can happen when a member persists its most recent view of another member > to disk, then that member is killed before it can remove the older view of > the other member from the op log files. When starting the cluster from disk, > the member then has two views of the other member, one recent and the other > stale. The member then decides is needs to wait for the stale view of the > other member which causes the hang. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5359) Infinite loop when a thread is interrupting during messaging
[
https://issues.apache.org/jira/browse/GEODE-5359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-5359:
-
Fix Version/s: 1.7.0
> Infinite loop when a thread is interrupting during messaging
>
>
> Key: GEODE-5359
> URL: https://issues.apache.org/jira/browse/GEODE-5359
> Project: Geode
> Issue Type: Bug
> Components: messaging
>Reporter: Dan Smith
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.7.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> This is similar to GEODE-5358, but it has a much easier fix. If a thread is
> interrupted while sending a message, it can get into an infinite loop because
> we keep reinterrupting the same thread and never clear the interrupt bit. The
> culprit is this line in DirectChannel.sendToMany
>
> {noformat}
> interrupted = interrupted || Thread.interrupted();{noformat}
> The issue is that if interrupted is already true, this won't call
> Thread.interrupted and clear the interrupt bit.
> The test checked into GEODE-5358 will reproduce this, but that can't be
> included with this fix because it still hangs due to GEODE-5358.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (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:comment-tabpanel=16594249#comment-16594249 ] Alexander Murmann commented on GEODE-5433: -- [~huynhja] Since we are having a discussion on the dev list about 1.7 and this happened since the last release, I am marking this as fixed in 1.7. Please correct this and let me know I screwed up if I did. > 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 > Fix For: 1.7.0 > > 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] [Updated] (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 ] Alexander Murmann updated GEODE-5433: - Fix Version/s: 1.7.0 > 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 > Fix For: 1.7.0 > > 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] [Commented] (GEODE-5472) PersistentPartitionedRegionRegressionTest recoversAfterBucketCreationCrashes hangs
[
https://issues.apache.org/jira/browse/GEODE-5472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16594243#comment-16594243
]
Alexander Murmann commented on GEODE-5472:
--
[~jinmeiliao] Since we are ramping up for 1.7 release and this happened since
the last release, I added the fix version accordingly. Please change back and
let me know I screwed up if I did.
> PersistentPartitionedRegionRegressionTest recoversAfterBucketCreationCrashes
> hangs
> --
>
> Key: GEODE-5472
> URL: https://issues.apache.org/jira/browse/GEODE-5472
> Project: Geode
> Issue Type: Bug
>Reporter: Jinmei Liao
>Assignee: Jinmei Liao
>Priority: Major
> Labels: pull-request-available, swat
> Fix For: 1.7.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/138]
>
> *{color:#cc3300}Pooled Waiting Message Processor 1{color}* is in deadlock
> with *{color:#cc3300}RMI TCP Connection(1)-172.17.0.5{color}*
> *{color:#003300}Pooled Waiting Message Processor 1{color}* - priority:10 -
> threadId:0x7ff740004800 - nativeId:0x498 -
> state:*{color:#cc3300}BLOCKED{color}*
> stackTrace:
> java.lang.Thread.State: BLOCKED (on object monitor)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.removeRoot({color:#80}GemFireCacheImpl.java:3604{color})
> - waiting to lock *<0xe0822280>* (a java.util.HashMap)
> at
> org.apache.geode.internal.cache.LocalRegion.basicDestroyRegion({color:#80}LocalRegion.java:6288{color})
> at
> org.apache.geode.internal.cache.DistributedRegion.basicDestroyRegion({color:#80}DistributedRegion.java:1730{color})
> at
> org.apache.geode.internal.cache.LocalRegion.basicDestroyRegion({color:#80}LocalRegion.java:6211{color})
> at
> org.apache.geode.internal.cache.LocalRegion.localDestroyRegion({color:#80}LocalRegion.java:2229{color})
> at
> org.apache.geode.internal.cache.AbstractRegion.localDestroyRegion({color:#80}AbstractRegion.java:424{color})
> at
> org.apache.geode.management.internal.ManagementResourceRepo.destroyLocalMonitoringRegion({color:#80}ManagementResourceRepo.java:73{color})
> at
> org.apache.geode.management.internal.LocalManager.cleanUpResources({color:#80}LocalManager.java:279{color})
> at
> org.apache.geode.management.internal.LocalManager.stopManager({color:#80}LocalManager.java:413{color})
> at
> org.apache.geode.management.internal.SystemManagementService.close({color:#80}SystemManagementService.java:240{color})
> - locked *<0xe03dcfe0>* (a java.util.HashMap)
> at
> org.apache.geode.management.internal.beans.ManagementAdapter.handleCacheRemoval({color:#80}ManagementAdapter.java:737{color})
> at
> org.apache.geode.management.internal.beans.ManagementListener.handleEvent({color:#80}ManagementListener.java:122{color})
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.notifyResourceEventListeners({color:#80}InternalDistributedSystem.java:2201{color})
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.handleResourceEvent({color:#80}InternalDistributedSystem.java:590{color})
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.close({color:#80}GemFireCacheImpl.java:2147{color})
> - locked *<0xe03dd028>* (a java.lang.Class for
> org.apache.geode.internal.cache.GemFireCacheImpl)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect({color:#80}InternalDistributedSystem.java:1371{color})
> - locked *<0xe03dd028>* (a java.lang.Class for
> org.apache.geode.internal.cache.GemFireCacheImpl)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect({color:#80}InternalDistributedSystem.java:1021{color})
> at
> org.apache.geode.test.dunit.Disconnect.disconnectFromDS({color:#80}Disconnect.java:43{color})
> at
> org.apache.geode.internal.cache.partitioned.PersistentPartitionedRegionRegressionTest$1.beforeSendMessage({color:#80}PersistentPartitionedRegionRegressionTest.java:288{color})
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.putOutgoing({color:#80}ClusterDistributionManager.java:1720{color})
> at
> org.apache.geode.internal.cache.partitioned.ManageBucketMessage$ManageBucketReplyMessage.sendAcceptance({color:#80}ManageBucketMessage.java:278{color})
> at
> org.apache.geode.internal.cache.partitioned.ManageBucketMessage.operateOnPartitionedRegion({color:#80}ManageBucketMessage.java:152{color})
> at
> org.apache.geode.internal.cache.partitioned.PartitionMessage.process({color:#80}PartitionMessage.java:331{color})
> at
>
[jira] [Updated] (GEODE-5472) PersistentPartitionedRegionRegressionTest recoversAfterBucketCreationCrashes hangs
[
https://issues.apache.org/jira/browse/GEODE-5472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-5472:
-
Fix Version/s: 1.7.0
> PersistentPartitionedRegionRegressionTest recoversAfterBucketCreationCrashes
> hangs
> --
>
> Key: GEODE-5472
> URL: https://issues.apache.org/jira/browse/GEODE-5472
> Project: Geode
> Issue Type: Bug
>Reporter: Jinmei Liao
>Assignee: Jinmei Liao
>Priority: Major
> Labels: pull-request-available, swat
> Fix For: 1.7.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/138]
>
> *{color:#cc3300}Pooled Waiting Message Processor 1{color}* is in deadlock
> with *{color:#cc3300}RMI TCP Connection(1)-172.17.0.5{color}*
> *{color:#003300}Pooled Waiting Message Processor 1{color}* - priority:10 -
> threadId:0x7ff740004800 - nativeId:0x498 -
> state:*{color:#cc3300}BLOCKED{color}*
> stackTrace:
> java.lang.Thread.State: BLOCKED (on object monitor)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.removeRoot({color:#80}GemFireCacheImpl.java:3604{color})
> - waiting to lock *<0xe0822280>* (a java.util.HashMap)
> at
> org.apache.geode.internal.cache.LocalRegion.basicDestroyRegion({color:#80}LocalRegion.java:6288{color})
> at
> org.apache.geode.internal.cache.DistributedRegion.basicDestroyRegion({color:#80}DistributedRegion.java:1730{color})
> at
> org.apache.geode.internal.cache.LocalRegion.basicDestroyRegion({color:#80}LocalRegion.java:6211{color})
> at
> org.apache.geode.internal.cache.LocalRegion.localDestroyRegion({color:#80}LocalRegion.java:2229{color})
> at
> org.apache.geode.internal.cache.AbstractRegion.localDestroyRegion({color:#80}AbstractRegion.java:424{color})
> at
> org.apache.geode.management.internal.ManagementResourceRepo.destroyLocalMonitoringRegion({color:#80}ManagementResourceRepo.java:73{color})
> at
> org.apache.geode.management.internal.LocalManager.cleanUpResources({color:#80}LocalManager.java:279{color})
> at
> org.apache.geode.management.internal.LocalManager.stopManager({color:#80}LocalManager.java:413{color})
> at
> org.apache.geode.management.internal.SystemManagementService.close({color:#80}SystemManagementService.java:240{color})
> - locked *<0xe03dcfe0>* (a java.util.HashMap)
> at
> org.apache.geode.management.internal.beans.ManagementAdapter.handleCacheRemoval({color:#80}ManagementAdapter.java:737{color})
> at
> org.apache.geode.management.internal.beans.ManagementListener.handleEvent({color:#80}ManagementListener.java:122{color})
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.notifyResourceEventListeners({color:#80}InternalDistributedSystem.java:2201{color})
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.handleResourceEvent({color:#80}InternalDistributedSystem.java:590{color})
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.close({color:#80}GemFireCacheImpl.java:2147{color})
> - locked *<0xe03dd028>* (a java.lang.Class for
> org.apache.geode.internal.cache.GemFireCacheImpl)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect({color:#80}InternalDistributedSystem.java:1371{color})
> - locked *<0xe03dd028>* (a java.lang.Class for
> org.apache.geode.internal.cache.GemFireCacheImpl)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect({color:#80}InternalDistributedSystem.java:1021{color})
> at
> org.apache.geode.test.dunit.Disconnect.disconnectFromDS({color:#80}Disconnect.java:43{color})
> at
> org.apache.geode.internal.cache.partitioned.PersistentPartitionedRegionRegressionTest$1.beforeSendMessage({color:#80}PersistentPartitionedRegionRegressionTest.java:288{color})
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.putOutgoing({color:#80}ClusterDistributionManager.java:1720{color})
> at
> org.apache.geode.internal.cache.partitioned.ManageBucketMessage$ManageBucketReplyMessage.sendAcceptance({color:#80}ManageBucketMessage.java:278{color})
> at
> org.apache.geode.internal.cache.partitioned.ManageBucketMessage.operateOnPartitionedRegion({color:#80}ManageBucketMessage.java:152{color})
> at
> org.apache.geode.internal.cache.partitioned.PartitionMessage.process({color:#80}PartitionMessage.java:331{color})
> at
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction({color:#80}DistributionMessage.java:378{color})
> at
> org.apache.geode.distributed.internal.DistributionMessage$1.run({color:#80}DistributionMessage.java:444{color})
> at
>
[jira] [Created] (GEODE-5646) Client throws ToDataException when locator is shutting down
Bruce Schuchardt created GEODE-5646:
---
Summary: Client throws ToDataException when locator is shutting
down
Key: GEODE-5646
URL: https://issues.apache.org/jira/browse/GEODE-5646
Project: Geode
Issue Type: Bug
Components: client/server
Reporter: Bruce Schuchardt
This hasn't been seen in Geode but in an older version of Pivotal GemFire. The
code in question hasn't changed so we ought to fix it.
{noformat}
ERROR util.TestException: doEntryOperations caught Exception
com.gemstone.gemfire.ToDataException: toData failed on DataSerializable class
com.gemstone.gemfire.distributed.internal.ServerLocation
at
com.gemstone.gemfire.internal.InternalDataSerializer.invokeToData(InternalDataSerializer.java:2424)
at
com.gemstone.gemfire.cache.client.internal.locator.SerializationHelper.writeServerLocations(SerializationHelper.java:39)
at
com.gemstone.gemfire.cache.client.internal.locator.SerializationHelper.writeServerLocationSet(SerializationHelper.java:75)
at
com.gemstone.gemfire.cache.client.internal.locator.ClientConnectionRequest.toData(ClientConnectionRequest.java:44)
at
com.gemstone.gemfire.internal.InternalDataSerializer.invokeToData(InternalDataSerializer.java:2411)
at
com.gemstone.gemfire.internal.InternalDataSerializer.writeDSFID(InternalDataSerializer.java:1382)
at
com.gemstone.gemfire.internal.InternalDataSerializer.basicWriteObject(InternalDataSerializer.java:2156)
at
com.gemstone.gemfire.DataSerializer.writeObject(DataSerializer.java:3181)
at
com.gemstone.org.jgroups.stack.tcpserver.TcpClient.requestToServer(TcpClient.java:115)
at
com.gemstone.org.jgroups.stack.tcpserver.TcpClient.requestToServer(TcpClient.java:78)
at
com.gemstone.gemfire.cache.client.internal.AutoConnectionSourceImpl.queryOneLocator(AutoConnectionSourceImpl.java:188)
at
com.gemstone.gemfire.cache.client.internal.AutoConnectionSourceImpl.queryLocators(AutoConnectionSourceImpl.java:220)
at
com.gemstone.gemfire.cache.client.internal.AutoConnectionSourceImpl.findServer(AutoConnectionSourceImpl.java:132)
at
com.gemstone.gemfire.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:227)
at
com.gemstone.gemfire.cache.client.internal.pooling.ConnectionManagerImpl.exchangeConnection(ConnectionManagerImpl.java:421)
at
com.gemstone.gemfire.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:173)
at
com.gemstone.gemfire.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:115)
at
com.gemstone.gemfire.cache.client.internal.PoolImpl.execute(PoolImpl.java:702)
at
com.gemstone.gemfire.cache.client.internal.KeySetOp.execute(KeySetOp.java:38)
at
com.gemstone.gemfire.cache.client.internal.ServerRegionProxy.keySet(ServerRegionProxy.java:348)
at
com.gemstone.gemfire.internal.cache.LocalRegion.keySetOnServer(LocalRegion.java:4159)
{noformat}
The client is trying to serialize ServerLocation objects and send them to a
locator. AutoConnectionSourceImpl.queryOneLocator() has code to handle
IOException and report the locator as being down but since ServerLocation isn't
a DataSerializableFixedID instance the serialization code throws a
ToDataException instead of an IOException. Adding ToDataException handling to
queryOneLocator() should fix the problem.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-5645) Client cache misses invalidate
Bruce Schuchardt created GEODE-5645:
---
Summary: Client cache misses invalidate
Key: GEODE-5645
URL: https://issues.apache.org/jira/browse/GEODE-5645
Project: Geode
Issue Type: Bug
Components: client queues
Reporter: Bruce Schuchardt
In a test with four clients and four servers with the clients performing
concurrent operations on the same keys one of the clients missed an
"invalidate" event and ended up being inconsistent.
There was a cache entry in the servers sitting at version 2. Client4 is the
cache that ends up being inconsistent by way of its subscription feed.
client1 does v3 invalidate with server1
client2 does v4 update with server2
client3 does v5 invalidate with server3
server4 receives v3 invalidate and informs clients
client4 gets v3 invalidate through subscription
server4 receives v5 invalidate and ignores it because its already invalidated
server4 receives v4 update from server2
server4 throws concurrency conflict exception for v4 update
client4 gets v4 update (applied as a create) from server4 through subscription
Clients with queues on other servers get the ops in order and end up with an
invalidated entry.
client4 does not get the final invalidate event and is inconsistent wrt other
clients and the servers.
With fine level logging the log statement that shows the problem happening is
this:
{noformat}
mapInvalidate: Entry already invalid: 'Object_1683'
{noformat}
Where Object_1683 is the key for the entry we're dealing with.
The code doing this is in AbstractRegionMap's invalidate() method:
{code}
if (oldRe.isInvalid()) {
// was already invalid, do not invoke listeners or
increment stat
if (isDebugEnabled) {
logger.debug("mapInvalidate: Entry already invalid:
'{}'",
event.getKey());
}
processVersionTag(oldRe, event);
try {
oldRe.setValue(owner, oldRe.getValueInVM(owner)); //
OFFHEAP noop setting
//
an already invalid to
//
invalid; No need to
//
call
//
prepareValueForCache
//
since it is an
//
invalid token.
} catch (RegionClearedException e) {
// that's okay - when writing an invalid into a disk,
the
// region has been cleared (including this token)
}
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (GEODE-5631) failedBatchRemovalMessageKeys never cleared
[ https://issues.apache.org/jira/browse/GEODE-5631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] nabarun closed GEODE-5631. -- > failedBatchRemovalMessageKeys never cleared > --- > > Key: GEODE-5631 > URL: https://issues.apache.org/jira/browse/GEODE-5631 > Project: Geode > Issue Type: Bug > Components: wan >Reporter: nabarun >Priority: Major > Labels: pull-request-available > Fix For: 1.7.0 > > Time Spent: 1h 20m > Remaining Estimate: 0h > > *+Experiment setup+*: > * Region A created with async event listener attached to it > * For every event processed by the async listener, a new entry is put into > another region, Region B. > * There is a client which does 1 million operations on 1500 keys on Region A. > [to trigger conflation.] > * 3 servers, 1 locator and 1 client. > +*Issue:*+ > It was confirmed that after upgrading to 1.6.0 , we saw an increase in the > memory footprint after all operations are completed. > +*Cause:*+ > * We had a data structure to store all the queue removal messages that comes > in when the secondary is in process of GII, called > failedBatchRemovalMessageKeys. > * Two removal messages were sent to the secondary for a single event, one > from the processor which was processing the event and another from the > conflation thread which conflated the event and hence wants the secondary to > remove it. > * Of the two messages whichever comes first, it removes the event from the > queue. > * When the second message comes in, and we try to remove it from the queue, > it hits an EntryNotFoundException. This makes the message think that > secondary is in GII and hence stores it in the failedBatchRemovalMessageKeys, > and expects that when GII is complete, this message will be processed. > * But GII was already done long before, and this data structure, > failedBatchRemovalMessageKeys keeps storing messages which are never removed > and hence a large memory footprint. > +*Fix:*+ > The data structure failedBatchRemovalMessageKeys is not used anymore if it > was already processed once, as GII happens once in a server’s lifecycle. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-5631) failedBatchRemovalMessageKeys never cleared
[ https://issues.apache.org/jira/browse/GEODE-5631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] nabarun resolved GEODE-5631. Resolution: Fixed Fix Version/s: 1.7.0 > failedBatchRemovalMessageKeys never cleared > --- > > Key: GEODE-5631 > URL: https://issues.apache.org/jira/browse/GEODE-5631 > Project: Geode > Issue Type: Bug > Components: wan >Reporter: nabarun >Priority: Major > Labels: pull-request-available > Fix For: 1.7.0 > > Time Spent: 1h 20m > Remaining Estimate: 0h > > *+Experiment setup+*: > * Region A created with async event listener attached to it > * For every event processed by the async listener, a new entry is put into > another region, Region B. > * There is a client which does 1 million operations on 1500 keys on Region A. > [to trigger conflation.] > * 3 servers, 1 locator and 1 client. > +*Issue:*+ > It was confirmed that after upgrading to 1.6.0 , we saw an increase in the > memory footprint after all operations are completed. > +*Cause:*+ > * We had a data structure to store all the queue removal messages that comes > in when the secondary is in process of GII, called > failedBatchRemovalMessageKeys. > * Two removal messages were sent to the secondary for a single event, one > from the processor which was processing the event and another from the > conflation thread which conflated the event and hence wants the secondary to > remove it. > * Of the two messages whichever comes first, it removes the event from the > queue. > * When the second message comes in, and we try to remove it from the queue, > it hits an EntryNotFoundException. This makes the message think that > secondary is in GII and hence stores it in the failedBatchRemovalMessageKeys, > and expects that when GII is complete, this message will be processed. > * But GII was already done long before, and this data structure, > failedBatchRemovalMessageKeys keeps storing messages which are never removed > and hence a large memory footprint. > +*Fix:*+ > The data structure failedBatchRemovalMessageKeys is not used anymore if it > was already processed once, as GII happens once in a server’s lifecycle. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5623) SUPERFLAKY: StopLocatorCommandDUnitTest
[
https://issues.apache.org/jira/browse/GEODE-5623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16594207#comment-16594207
]
ASF subversion and git services commented on GEODE-5623:
Commit a3830536834fa70dbf00bd70ce381c94bf264307 in geode's branch
refs/heads/feature/GEODE-5624 from Dan Smith
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=a383053 ]
GEODE-5623: Use Awaitility in StopLcoatorCommandDUnitTest (#2379)
Apparently members are not immmediately visible to stop after gfsh start
locator. Changing the test to use awaitility to wait until the members
can be stopped.
> SUPERFLAKY: StopLocatorCommandDUnitTest
> ---
>
> Key: GEODE-5623
> URL: https://issues.apache.org/jira/browse/GEODE-5623
> Project: Geode
> Issue Type: Bug
>Reporter: Dan Smith
>Assignee: Dan Smith
>Priority: Major
> Labels: pull-request-available, swat
> Fix For: 1.7.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> This test failed recently in CI, and it failed multiple times in the a 300
> run batch of DistributedTest
> Most recent failure:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/281
> {noformat}
> org.apache.geode.management.internal.cli.commands.StopLocatorCommandDUnitTest
> > testWithMemberName FAILED
>
> org.junit.ComparisonFailure: expected:<[OK]> but was:<[ERROR]>
> 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.management.internal.cli.commands.StopLocatorCommandDUnitTest.testWithMemberName(StopLocatorCommandDUnitTest.java:159)
> {noformat}
> In the 300 run batch, to two different methods in this class are failing:
> {noformat}
> org.apache.geode.management.internal.cli.commands.StopLocatorCommandDUnitTest:
> 9 failures (97.000% success rate)
> | .testWithMemberID: 2 failures (99.333% success rate)
> | | Failed build 286 at
> https://concourse.apachegeode-ci.info/teams/staging/pipelines/concourse-staging/jobs/DistributedTest/builds/286
> | | Failed build 146 at
> https://concourse.apachegeode-ci.info/teams/staging/pipelines/concourse-staging/jobs/DistributedTest/builds/146
> | .testWithMemberName: 7 failures (97.667% success rate)
> | | Failed build 260 at
> https://concourse.apachegeode-ci.info/teams/staging/pipelines/concourse-staging/jobs/DistributedTest/builds/260
> | | Failed build 231 at
> https://concourse.apachegeode-ci.info/teams/staging/pipelines/concourse-staging/jobs/DistributedTest/builds/231
> | | Failed build 178 at
> https://concourse.apachegeode-ci.info/teams/staging/pipelines/concourse-staging/jobs/DistributedTest/builds/178
> | | Failed build 127 at
> https://concourse.apachegeode-ci.info/teams/staging/pipelines/concourse-staging/jobs/DistributedTest/builds/127
> | | Failed build 87 at
> https://concourse.apachegeode-ci.info/teams/staging/pipelines/concourse-staging/jobs/DistributedTest/builds/87
> | | Failed build 53 at
> https://concourse.apachegeode-ci.info/teams/staging/pipelines/concourse-staging/jobs/DistributedTest/builds/53
> | | Failed build 27 at
> https://concourse.apachegeode-ci.info/teams/staging/pipelines/concourse-staging/jobs/DistributedTest/builds/27
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5614) Rename DistributedTestRule as DistributedRule
[ https://issues.apache.org/jira/browse/GEODE-5614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16594205#comment-16594205 ] ASF subversion and git services commented on GEODE-5614: Commit f91c2dfa319073ddb1222c3f50c26735d19332fe in geode's branch refs/heads/feature/GEODE-5624 from [~apa...@the9muses.net] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=f91c2df ] GEODE-5614: update RegionManagementDUnitTest usage of DistributedRule > Rename DistributedTestRule as DistributedRule > - > > Key: GEODE-5614 > URL: https://issues.apache.org/jira/browse/GEODE-5614 > Project: Geode > Issue Type: Improvement > Components: tests >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Labels: pull-request-available > Fix For: 1.7.0 > > Time Spent: 50m > Remaining Estimate: 0h > > Rename DistributedTestRule as DistributedRule. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5597) Upload geode maven snapshot artifacts from concourse
[ https://issues.apache.org/jira/browse/GEODE-5597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16594211#comment-16594211 ] ASF subversion and git services commented on GEODE-5597: Commit 76af1dd2fc5dc35a80f61066645978bbb382f417 in geode's branch refs/heads/feature/GEODE-5624 from FSOUTHERLAND [ https://gitbox.apache.org/repos/asf?p=geode.git;h=76af1dd ] GEODE-5597 Publish geode artifacts to maven repo on GCS (#2347) * Uses vanilla maven-publish Gradle plugin, instead of nexus (nexus is still used for release artifact publishing) * GCS credentials are inherited from the concourse worker Co-authored-by: Finn Southerland Co-authored-by: Jake Barrett > Upload geode maven snapshot artifacts from concourse > > > Key: GEODE-5597 > URL: https://issues.apache.org/jira/browse/GEODE-5597 > Project: Geode > Issue Type: Task > Components: ci >Reporter: Finn Southerland >Priority: Major > Labels: pull-request-available > Time Spent: 7h 50m > Remaining Estimate: 0h > > We would like to publish snapshots from concourse, rather than jenkins. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5624) JTA transaction does not clean up TXState due to IllegalMonitorStateException
[
https://issues.apache.org/jira/browse/GEODE-5624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16594212#comment-16594212
]
ASF subversion and git services commented on GEODE-5624:
Commit 5ebd326244f3033abf70610251eab2416b7688df in geode's branch
refs/heads/feature/GEODE-5624 from eshu
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=5ebd326 ]
Merge remote-tracking branch 'origin/develop' into feature/GEODE-5624
> JTA transaction does not clean up TXState due to IllegalMonitorStateException
> -
>
> Key: GEODE-5624
> URL: https://issues.apache.org/jira/browse/GEODE-5624
> Project: Geode
> Issue Type: Bug
> Components: transactions
>Reporter: Eric Shu
>Assignee: Eric Shu
>Priority: Major
>
> When server has different threads handling JTA beforeCompletion and
> afterCompletion, IllegalMonitorStateException can be thrown when release
> locks held. This causes the TXState not being cleaned up.
> {noformat}
> java.lang.IllegalMonitorStateException: attempt to unlock read lock, not
> locked by current thread
> at
> java.util.concurrent.locks.ReentrantReadWriteLock$Sync.unmatchedUnlockException(ReentrantReadWriteLock.java:444)
> at
> java.util.concurrent.locks.ReentrantReadWriteLock$Sync.tryReleaseShared(ReentrantReadWriteLock.java:428)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.releaseShared(AbstractQueuedSynchronizer.java:1341)
> at
> java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.unlock(ReentrantReadWriteLock.java:881)
> at
> org.apache.geode.internal.util.concurrent.StoppableReentrantReadWriteLock$StoppableReadLock.unlock(StoppableReentrantReadWriteLock.java:144)
> at
> org.apache.geode.internal.cache.locks.TXLockServiceImpl.releaseRecoveryReadLock(TXLockServiceImpl.java:275)
> at
> org.apache.geode.internal.cache.locks.TXLockServiceImpl.release(TXLockServiceImpl.java:240)
> at
> org.apache.geode.internal.cache.TXLockRequest.releaseDistributed(TXLockRequest.java:109)
> at
> org.apache.geode.internal.cache.TXLockRequest.cleanup(TXLockRequest.java:142)
> at org.apache.geode.internal.cache.TXState.cleanup(TXState.java:870)
> at org.apache.geode.internal.cache.TXState.commit(TXState.java:514)
> at
> org.apache.geode.internal.cache.TXState.doAfterCompletion(TXState.java:1103)
> at
> org.apache.geode.internal.cache.TXState.afterCompletion(TXState.java:1084)
> at
> org.apache.geode.internal.cache.TXStateProxyImpl.afterCompletion(TXStateProxyImpl.java:452)
> at
> org.apache.geode.internal.cache.tier.sockets.command.TXSynchronizationCommand.cmdExecute(TXSynchronizationCommand.java:140)
> at
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:158)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMsg(ServerConnection.java:869)
> at
> org.apache.geode.internal.cache.tier.sockets.OriginalServerConnection.doOneMessage(OriginalServerConnection.java:77)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1248)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl$4$1.run(AcceptorImpl.java:645)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5631) failedBatchRemovalMessageKeys never cleared
[ https://issues.apache.org/jira/browse/GEODE-5631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16594208#comment-16594208 ] ASF subversion and git services commented on GEODE-5631: Commit 85953f085b13815405cb9bf3c5b1bca77c3c9a5e in geode's branch refs/heads/feature/GEODE-5624 from [~nabarunnag] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=85953f0 ] GEODE-5631: failedBatchRemovalMessageKeys not used after GII (#2375) * After GII a flag is set to indicate that failedBatchRemovalMessageKeys has been processed * If this flag is set, no more entries will be put into failedBatchRemovalMessageKeys. > failedBatchRemovalMessageKeys never cleared > --- > > Key: GEODE-5631 > URL: https://issues.apache.org/jira/browse/GEODE-5631 > Project: Geode > Issue Type: Bug > Components: wan >Reporter: nabarun >Priority: Major > Labels: pull-request-available > Time Spent: 1h 20m > Remaining Estimate: 0h > > *+Experiment setup+*: > * Region A created with async event listener attached to it > * For every event processed by the async listener, a new entry is put into > another region, Region B. > * There is a client which does 1 million operations on 1500 keys on Region A. > [to trigger conflation.] > * 3 servers, 1 locator and 1 client. > +*Issue:*+ > It was confirmed that after upgrading to 1.6.0 , we saw an increase in the > memory footprint after all operations are completed. > +*Cause:*+ > * We had a data structure to store all the queue removal messages that comes > in when the secondary is in process of GII, called > failedBatchRemovalMessageKeys. > * Two removal messages were sent to the secondary for a single event, one > from the processor which was processing the event and another from the > conflation thread which conflated the event and hence wants the secondary to > remove it. > * Of the two messages whichever comes first, it removes the event from the > queue. > * When the second message comes in, and we try to remove it from the queue, > it hits an EntryNotFoundException. This makes the message think that > secondary is in GII and hence stores it in the failedBatchRemovalMessageKeys, > and expects that when GII is complete, this message will be processed. > * But GII was already done long before, and this data structure, > failedBatchRemovalMessageKeys keeps storing messages which are never removed > and hence a large memory footprint. > +*Fix:*+ > The data structure failedBatchRemovalMessageKeys is not used anymore if it > was already processed once, as GII happens once in a server’s lifecycle. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5629) GMSEncryptJUnitTest does not actually check the results of threads it starts
[
https://issues.apache.org/jira/browse/GEODE-5629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16594206#comment-16594206
]
ASF subversion and git services commented on GEODE-5629:
Commit e719331d03b3e3b1ae069b9db5b04cc928b96e3f in geode's branch
refs/heads/feature/GEODE-5624 from Dan Smith
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=e719331 ]
GEODE-5629: Changing GMSEncryptJUnitTest to use ConcurrencyRule
This test was not capturing exceptions from the background threads.
Using ConcurrenyRule to execute the background tests.
> GMSEncryptJUnitTest does not actually check the results of threads it starts
>
>
> Key: GEODE-5629
> URL: https://issues.apache.org/jira/browse/GEODE-5629
> Project: Geode
> Issue Type: Bug
>Reporter: Dan Smith
>Assignee: Dan Smith
>Priority: Major
> Labels: pull-request-available, swat
> Time Spent: 1h
> Remaining Estimate: 0h
>
> The testForClusterSecretKeyFromOtherMemberMultipleThreads method starts a
> bunch of threads, but it does not actually check to see if they ran
> successfully without an exception. It just waits for them to finish around
> line 362. This test should be refactored to use the ConcurrencyRule.
> {code}
> countDownLatch.await();
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5620) Add project property to control fork parallelism
[
https://issues.apache.org/jira/browse/GEODE-5620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16594210#comment-16594210
]
ASF subversion and git services commented on GEODE-5620:
Commit 0cbf8e5e5221b9d397edbca26a03995c8ed20a68 in geode's branch
refs/heads/feature/GEODE-5624 from [~bschuchardt]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=0cbf8e5 ]
GEODE-5620: Adds project property to control test forking
Fixing testMaxParalleForks property handling. The code was using
the character code for the number assigned to the property. It needed
to parse the value to turn it into the requested number.
> Add project property to control fork parallelism
>
>
> Key: GEODE-5620
> URL: https://issues.apache.org/jira/browse/GEODE-5620
> Project: Geode
> Issue Type: Improvement
> Components: build
>Reporter: Jacob S. Barrett
>Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Add {{-PtestMaxParallelForks}} project property to control max parallel forks.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5614) Rename DistributedTestRule as DistributedRule
[ https://issues.apache.org/jira/browse/GEODE-5614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16594204#comment-16594204 ] ASF subversion and git services commented on GEODE-5614: Commit 16d0f6962a1c11d5f09e21ab67e23e1686d14934 in geode's branch refs/heads/feature/GEODE-5624 from [~apa...@the9muses.net] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=16d0f69 ] GEODE-5614: rename distributedTestRule field to distributedRule * Cleanup warnings in these tests > Rename DistributedTestRule as DistributedRule > - > > Key: GEODE-5614 > URL: https://issues.apache.org/jira/browse/GEODE-5614 > Project: Geode > Issue Type: Improvement > Components: tests >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Labels: pull-request-available > Fix For: 1.7.0 > > Time Spent: 50m > Remaining Estimate: 0h > > Rename DistributedTestRule as DistributedRule. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5630) Some tests using await should use until instead of untilAsserted
[
https://issues.apache.org/jira/browse/GEODE-5630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16594209#comment-16594209
]
ASF subversion and git services commented on GEODE-5630:
Commit 45138b4861ff882006000c953a823b4ecc4a5fdd in geode's branch
refs/heads/feature/GEODE-5624 from [~apa...@the9muses.net]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=45138b4 ]
GEODE-5630: fixup usage of Awaitility
> Some tests using await should use until instead of untilAsserted
>
>
> Key: GEODE-5630
> URL: https://issues.apache.org/jira/browse/GEODE-5630
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.7.0
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> Awaitility was upgraded for GEODE-5593 and most or all of the
> await()...until() calls were changed to await()...untilAsserted(). One or
> more of these that are now incorrect.
> BucketCreationCrashCompletesRegressionTest line 173 is now:
> {noformat}
> await().atMost(2, MINUTES).untilAsserted(() -> {
> hasBucketOwners(partitionedRegion, bucketId);
> });
> {noformat}
> But hasBucketOwners returns a boolean and does not perform any assertions.
> I'll fix this test and then review every other test that was changed to use
> untilAsserted.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5623) SUPERFLAKY: StopLocatorCommandDUnitTest
[
https://issues.apache.org/jira/browse/GEODE-5623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16594194#comment-16594194
]
ASF subversion and git services commented on GEODE-5623:
Commit a3830536834fa70dbf00bd70ce381c94bf264307 in geode's branch
refs/heads/concourse-staging from Dan Smith
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=a383053 ]
GEODE-5623: Use Awaitility in StopLcoatorCommandDUnitTest (#2379)
Apparently members are not immmediately visible to stop after gfsh start
locator. Changing the test to use awaitility to wait until the members
can be stopped.
> SUPERFLAKY: StopLocatorCommandDUnitTest
> ---
>
> Key: GEODE-5623
> URL: https://issues.apache.org/jira/browse/GEODE-5623
> Project: Geode
> Issue Type: Bug
>Reporter: Dan Smith
>Assignee: Dan Smith
>Priority: Major
> Labels: pull-request-available, swat
> Fix For: 1.7.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> This test failed recently in CI, and it failed multiple times in the a 300
> run batch of DistributedTest
> Most recent failure:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/281
> {noformat}
> org.apache.geode.management.internal.cli.commands.StopLocatorCommandDUnitTest
> > testWithMemberName FAILED
>
> org.junit.ComparisonFailure: expected:<[OK]> but was:<[ERROR]>
> 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.management.internal.cli.commands.StopLocatorCommandDUnitTest.testWithMemberName(StopLocatorCommandDUnitTest.java:159)
> {noformat}
> In the 300 run batch, to two different methods in this class are failing:
> {noformat}
> org.apache.geode.management.internal.cli.commands.StopLocatorCommandDUnitTest:
> 9 failures (97.000% success rate)
> | .testWithMemberID: 2 failures (99.333% success rate)
> | | Failed build 286 at
> https://concourse.apachegeode-ci.info/teams/staging/pipelines/concourse-staging/jobs/DistributedTest/builds/286
> | | Failed build 146 at
> https://concourse.apachegeode-ci.info/teams/staging/pipelines/concourse-staging/jobs/DistributedTest/builds/146
> | .testWithMemberName: 7 failures (97.667% success rate)
> | | Failed build 260 at
> https://concourse.apachegeode-ci.info/teams/staging/pipelines/concourse-staging/jobs/DistributedTest/builds/260
> | | Failed build 231 at
> https://concourse.apachegeode-ci.info/teams/staging/pipelines/concourse-staging/jobs/DistributedTest/builds/231
> | | Failed build 178 at
> https://concourse.apachegeode-ci.info/teams/staging/pipelines/concourse-staging/jobs/DistributedTest/builds/178
> | | Failed build 127 at
> https://concourse.apachegeode-ci.info/teams/staging/pipelines/concourse-staging/jobs/DistributedTest/builds/127
> | | Failed build 87 at
> https://concourse.apachegeode-ci.info/teams/staging/pipelines/concourse-staging/jobs/DistributedTest/builds/87
> | | Failed build 53 at
> https://concourse.apachegeode-ci.info/teams/staging/pipelines/concourse-staging/jobs/DistributedTest/builds/53
> | | Failed build 27 at
> https://concourse.apachegeode-ci.info/teams/staging/pipelines/concourse-staging/jobs/DistributedTest/builds/27
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5629) GMSEncryptJUnitTest does not actually check the results of threads it starts
[
https://issues.apache.org/jira/browse/GEODE-5629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16594193#comment-16594193
]
ASF subversion and git services commented on GEODE-5629:
Commit e719331d03b3e3b1ae069b9db5b04cc928b96e3f in geode's branch
refs/heads/concourse-staging from Dan Smith
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=e719331 ]
GEODE-5629: Changing GMSEncryptJUnitTest to use ConcurrencyRule
This test was not capturing exceptions from the background threads.
Using ConcurrenyRule to execute the background tests.
> GMSEncryptJUnitTest does not actually check the results of threads it starts
>
>
> Key: GEODE-5629
> URL: https://issues.apache.org/jira/browse/GEODE-5629
> Project: Geode
> Issue Type: Bug
>Reporter: Dan Smith
>Assignee: Dan Smith
>Priority: Major
> Labels: pull-request-available, swat
> Time Spent: 1h
> Remaining Estimate: 0h
>
> The testForClusterSecretKeyFromOtherMemberMultipleThreads method starts a
> bunch of threads, but it does not actually check to see if they ran
> successfully without an exception. It just waits for them to finish around
> line 362. This test should be refactored to use the ConcurrencyRule.
> {code}
> countDownLatch.await();
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5614) Rename DistributedTestRule as DistributedRule
[ https://issues.apache.org/jira/browse/GEODE-5614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16594192#comment-16594192 ] ASF subversion and git services commented on GEODE-5614: Commit f91c2dfa319073ddb1222c3f50c26735d19332fe in geode's branch refs/heads/concourse-staging from [~apa...@the9muses.net] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=f91c2df ] GEODE-5614: update RegionManagementDUnitTest usage of DistributedRule > Rename DistributedTestRule as DistributedRule > - > > Key: GEODE-5614 > URL: https://issues.apache.org/jira/browse/GEODE-5614 > Project: Geode > Issue Type: Improvement > Components: tests >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Labels: pull-request-available > Fix For: 1.7.0 > > Time Spent: 50m > Remaining Estimate: 0h > > Rename DistributedTestRule as DistributedRule. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5631) failedBatchRemovalMessageKeys never cleared
[ https://issues.apache.org/jira/browse/GEODE-5631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16594195#comment-16594195 ] ASF subversion and git services commented on GEODE-5631: Commit 85953f085b13815405cb9bf3c5b1bca77c3c9a5e in geode's branch refs/heads/concourse-staging from [~nabarunnag] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=85953f0 ] GEODE-5631: failedBatchRemovalMessageKeys not used after GII (#2375) * After GII a flag is set to indicate that failedBatchRemovalMessageKeys has been processed * If this flag is set, no more entries will be put into failedBatchRemovalMessageKeys. > failedBatchRemovalMessageKeys never cleared > --- > > Key: GEODE-5631 > URL: https://issues.apache.org/jira/browse/GEODE-5631 > Project: Geode > Issue Type: Bug > Components: wan >Reporter: nabarun >Priority: Major > Labels: pull-request-available > Time Spent: 1h 20m > Remaining Estimate: 0h > > *+Experiment setup+*: > * Region A created with async event listener attached to it > * For every event processed by the async listener, a new entry is put into > another region, Region B. > * There is a client which does 1 million operations on 1500 keys on Region A. > [to trigger conflation.] > * 3 servers, 1 locator and 1 client. > +*Issue:*+ > It was confirmed that after upgrading to 1.6.0 , we saw an increase in the > memory footprint after all operations are completed. > +*Cause:*+ > * We had a data structure to store all the queue removal messages that comes > in when the secondary is in process of GII, called > failedBatchRemovalMessageKeys. > * Two removal messages were sent to the secondary for a single event, one > from the processor which was processing the event and another from the > conflation thread which conflated the event and hence wants the secondary to > remove it. > * Of the two messages whichever comes first, it removes the event from the > queue. > * When the second message comes in, and we try to remove it from the queue, > it hits an EntryNotFoundException. This makes the message think that > secondary is in GII and hence stores it in the failedBatchRemovalMessageKeys, > and expects that when GII is complete, this message will be processed. > * But GII was already done long before, and this data structure, > failedBatchRemovalMessageKeys keeps storing messages which are never removed > and hence a large memory footprint. > +*Fix:*+ > The data structure failedBatchRemovalMessageKeys is not used anymore if it > was already processed once, as GII happens once in a server’s lifecycle. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5614) Rename DistributedTestRule as DistributedRule
[ https://issues.apache.org/jira/browse/GEODE-5614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16594190#comment-16594190 ] ASF subversion and git services commented on GEODE-5614: Commit 123b8c4b3a415598c9edd5a1c311b94a75ce9edf in geode's branch refs/heads/concourse-staging from [~apa...@the9muses.net] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=123b8c4 ] GEODE-5614: rename DistributedTestRule as DistributedRule * Cleanup javadocs on rules that referred to DistributedTestRule. * Add ClientCacheFactoryDistributedTest for ClientCacheRule. > Rename DistributedTestRule as DistributedRule > - > > Key: GEODE-5614 > URL: https://issues.apache.org/jira/browse/GEODE-5614 > Project: Geode > Issue Type: Improvement > Components: tests >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Labels: pull-request-available > Fix For: 1.7.0 > > Time Spent: 50m > Remaining Estimate: 0h > > Rename DistributedTestRule as DistributedRule. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5620) Add project property to control fork parallelism
[
https://issues.apache.org/jira/browse/GEODE-5620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16594197#comment-16594197
]
ASF subversion and git services commented on GEODE-5620:
Commit 0cbf8e5e5221b9d397edbca26a03995c8ed20a68 in geode's branch
refs/heads/concourse-staging from [~bschuchardt]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=0cbf8e5 ]
GEODE-5620: Adds project property to control test forking
Fixing testMaxParalleForks property handling. The code was using
the character code for the number assigned to the property. It needed
to parse the value to turn it into the requested number.
> Add project property to control fork parallelism
>
>
> Key: GEODE-5620
> URL: https://issues.apache.org/jira/browse/GEODE-5620
> Project: Geode
> Issue Type: Improvement
> Components: build
>Reporter: Jacob S. Barrett
>Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Add {{-PtestMaxParallelForks}} project property to control max parallel forks.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5630) Some tests using await should use until instead of untilAsserted
[
https://issues.apache.org/jira/browse/GEODE-5630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16594196#comment-16594196
]
ASF subversion and git services commented on GEODE-5630:
Commit 45138b4861ff882006000c953a823b4ecc4a5fdd in geode's branch
refs/heads/concourse-staging from [~apa...@the9muses.net]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=45138b4 ]
GEODE-5630: fixup usage of Awaitility
> Some tests using await should use until instead of untilAsserted
>
>
> Key: GEODE-5630
> URL: https://issues.apache.org/jira/browse/GEODE-5630
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.7.0
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> Awaitility was upgraded for GEODE-5593 and most or all of the
> await()...until() calls were changed to await()...untilAsserted(). One or
> more of these that are now incorrect.
> BucketCreationCrashCompletesRegressionTest line 173 is now:
> {noformat}
> await().atMost(2, MINUTES).untilAsserted(() -> {
> hasBucketOwners(partitionedRegion, bucketId);
> });
> {noformat}
> But hasBucketOwners returns a boolean and does not perform any assertions.
> I'll fix this test and then review every other test that was changed to use
> untilAsserted.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5614) Rename DistributedTestRule as DistributedRule
[ https://issues.apache.org/jira/browse/GEODE-5614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16594191#comment-16594191 ] ASF subversion and git services commented on GEODE-5614: Commit 16d0f6962a1c11d5f09e21ab67e23e1686d14934 in geode's branch refs/heads/concourse-staging from [~apa...@the9muses.net] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=16d0f69 ] GEODE-5614: rename distributedTestRule field to distributedRule * Cleanup warnings in these tests > Rename DistributedTestRule as DistributedRule > - > > Key: GEODE-5614 > URL: https://issues.apache.org/jira/browse/GEODE-5614 > Project: Geode > Issue Type: Improvement > Components: tests >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Labels: pull-request-available > Fix For: 1.7.0 > > Time Spent: 50m > Remaining Estimate: 0h > > Rename DistributedTestRule as DistributedRule. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5142) new Thread Monitoring Mechanism
[ https://issues.apache.org/jira/browse/GEODE-5142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16594189#comment-16594189 ] ASF subversion and git services commented on GEODE-5142: Commit b9511465702bf746c1543a6a5eb2369f22f88fb3 in geode's branch refs/heads/concourse-staging from [~bschuchardt] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=b951146 ] GEODE-5142 new Thread Monitoring Mechanism Fixing some formatting problems in stack trace output and other log messages. One person noticed the monitor saying it was "expiring" a thread and thought it was doing something other than print stack traces. > new Thread Monitoring Mechanism > --- > > Key: GEODE-5142 > URL: https://issues.apache.org/jira/browse/GEODE-5142 > Project: Geode > Issue Type: New Feature > Components: docs, management >Reporter: yossi reginiano >Assignee: Joey McAllister >Priority: Major > Labels: pull-request-available > Time Spent: 6h 20m > Remaining Estimate: 0h > > One of the most severe issues hitting our real time application is thread > stuck for multiple reasons, such as long lasting locks, deadlocks, threads > which wait for reply forever in case of packet drop issue etc... > Such kind of stuck are under Radar of the existing system health check > methods. In mission critical applications, this will be resulted as an > immediate outage. > Here we introduce thread monitoring mechanism, to detect threads which are > stuck for any reason. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5597) Upload geode maven snapshot artifacts from concourse
[ https://issues.apache.org/jira/browse/GEODE-5597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16594187#comment-16594187 ] ASF subversion and git services commented on GEODE-5597: Commit 76af1dd2fc5dc35a80f61066645978bbb382f417 in geode's branch refs/heads/develop from FSOUTHERLAND [ https://gitbox.apache.org/repos/asf?p=geode.git;h=76af1dd ] GEODE-5597 Publish geode artifacts to maven repo on GCS (#2347) * Uses vanilla maven-publish Gradle plugin, instead of nexus (nexus is still used for release artifact publishing) * GCS credentials are inherited from the concourse worker Co-authored-by: Finn Southerland Co-authored-by: Jake Barrett > Upload geode maven snapshot artifacts from concourse > > > Key: GEODE-5597 > URL: https://issues.apache.org/jira/browse/GEODE-5597 > Project: Geode > Issue Type: Task > Components: ci >Reporter: Finn Southerland >Priority: Major > Labels: pull-request-available > Time Spent: 7h 50m > Remaining Estimate: 0h > > We would like to publish snapshots from concourse, rather than jenkins. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-4273) org.apache.geode.internal.cache.DiskRegionJUnitTest.testEntryDestructionInSynchPersistOnlyForIOExceptionCase fails with IllegalStateException
[ https://issues.apache.org/jira/browse/GEODE-4273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund reassigned GEODE-4273: Assignee: Kirk Lund > org.apache.geode.internal.cache.DiskRegionJUnitTest.testEntryDestructionInSynchPersistOnlyForIOExceptionCase > fails with IllegalStateException > - > > Key: GEODE-4273 > URL: https://issues.apache.org/jira/browse/GEODE-4273 > Project: Geode > Issue Type: Bug > Components: persistence >Reporter: Lynn Gallinat >Assignee: Kirk Lund >Priority: Major > Labels: flaky, swat > > org.apache.geode.internal.cache.DiskRegionJUnitTest > > testEntryDestructionInSynchPersistOnlyForIOExceptionCase FAILED > java.lang.IllegalStateException: A connection to a distributed system > already exists in this VM. It has the following configuration: > ack-severe-alert-threshold="0" > ack-wait-threshold="15" > archive-disk-space-limit="0" > archive-file-size-limit="0" > async-distribution-timeout="0" > async-max-queue-size="8" > async-queue-timeout="6" > bind-address="" > cache-xml-file="cache.xml" > cluster-configuration-dir="" > cluster-ssl-ciphers="any" > cluster-ssl-enabled="false" > cluster-ssl-keystore="" > cluster-ssl-keystore-password="" > cluster-ssl-keystore-type="" > cluster-ssl-protocols="any" > cluster-ssl-require-authentication="true" > cluster-ssl-truststore="" > cluster-ssl-truststore-password="" > conflate-events="server" > conserve-sockets="true" > delta-propagation="true" > > deploy-working-dir="/tmp/build/ae3c03f4/built-geode/test/geode-core/build/integrationTest" > disable-auto-reconnect="false" > disable-tcp="false" > distributed-system-id="-1" > distributed-transactions="false" > durable-client-id="" > durable-client-timeout="300" > enable-cluster-configuration="true" > enable-network-partition-detection="true" > enable-time-statistics="true" > enforce-unique-host="false" > gateway-ssl-ciphers="any" > gateway-ssl-enabled="false" > gateway-ssl-keystore="" > gateway-ssl-keystore-password="" > gateway-ssl-keystore-type="" > gateway-ssl-protocols="any" > gateway-ssl-require-authentication="true" > gateway-ssl-truststore="" > gateway-ssl-truststore-password="" > groups="" > http-service-bind-address="" > http-service-port="7070" > http-service-ssl-ciphers="any" > http-service-ssl-enabled="false" > http-service-ssl-keystore="" > http-service-ssl-keystore-password="" > http-service-ssl-keystore-type="" > http-service-ssl-protocols="any" > http-service-ssl-require-authentication="false" > http-service-ssl-truststore="" > http-service-ssl-truststore-password="" > jmx-manager="false" > jmx-manager-access-file="" > jmx-manager-bind-address="" > jmx-manager-hostname-for-clients="" > jmx-manager-http-port="7070" > jmx-manager-password-file="" > jmx-manager-port="1099" > jmx-manager-ssl-ciphers="any" > jmx-manager-ssl-enabled="false" > jmx-manager-ssl-keystore="" > jmx-manager-ssl-keystore-password="" > jmx-manager-ssl-keystore-type="" > jmx-manager-ssl-protocols="any" > jmx-manager-ssl-require-authentication="true" > jmx-manager-ssl-truststore="" > jmx-manager-ssl-truststore-password="" > jmx-manager-start="false" > jmx-manager-update-rate="2000" > load-cluster-configuration-from-dir="false" > locator-wait-time="0" > locators="" > lock-memory="false" > log-disk-space-limit="0" > log-file="" > log-file-size-limit="0" > log-level="config" > max-num-reconnect-tries="3" > max-wait-time-reconnect="6" > mcast-address="/239.192.81.1" > mcast-flow-control="1048576, 0.25, 5000" > mcast-port="0" > mcast-recv-buffer-size="1048576" > mcast-send-buffer-size="65535" > mcast-ttl="32" > member-timeout="5000" > membership-port-range="[1024,65535]" > memcached-bind-address="" > memcached-port="0" > memcached-protocol="ASCII" > name="" > off-heap-memory-size="" > redis-bind-address="" > redis-password="" > redis-port="0" > redundancy-zone="" > remote-locators="" > remove-unresponsive-client="false" > roles="" > security-client-accessor="" > security-client-accessor-pp="" > security-client-auth-init="" > security-client-authenticator=""
[jira] [Updated] (GEODE-5639) Replace usage of CatchException with AssertJ and remove CatchException dependency
[
https://issues.apache.org/jira/browse/GEODE-5639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-5639:
--
Labels: pull-request-available (was: )
> Replace usage of CatchException with AssertJ and remove CatchException
> dependency
> -
>
> Key: GEODE-5639
> URL: https://issues.apache.org/jira/browse/GEODE-5639
> Project: Geode
> Issue Type: Wish
> Components: build, tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Labels: pull-request-available
>
> We have a small number of tests using
> com.googlecode.catchexception.CatchException. This project isn't very active
> and AssertJ provides better support for testing expected exceptions and
> throwables. Most Geode developers are already using AssertJ for expected
> exceptions.
> The tests using CatchException should be updated to instead use AssertJ and
> then remove our testing dependency on CatchException.
> The recommended ways of handling expected exception testing would then
> involve using following AssertJ APIs:
> 1) Basic assertion about an expected exception
> Use: org.assertj.core.api.Assertions.assertThatThrownBy
> Example from JdbcWriterTest:
> {noformat}
> assertThatThrownBy(() -> writer.beforeUpdate(entryEvent))
> .isInstanceOf(IllegalArgumentException.class);
> {noformat}
> 2) Complex assertion about an expected exception (potentially with many
> nested causes with messages that we want to validate as well)
> Use: org.assertj.core.api.Assertions.catchThrowable
> Example from DeltaPropagationFailureRegressionTest:
> {noformat}
> Throwable thrown = server1.invoke(() -> catchThrowable(() ->
> putDelta(FROM_DELTA)));
> assertThat(thrown).isInstanceOf(DeltaSerializationException.class)
> .hasMessageContaining("deserializing delta
> bytes").hasCauseInstanceOf(EOFException.class);
> {noformat}
> 3) Simple assertion that an invocation should not thrown (probably used in a
> regression test)
> Use: org.assertj.core.api.Assertions.assertThatCode
> Example from RegisterInterestDistributedTest:
> {noformat}
> assertThatCode(() ->
> clientCache.readyForEvents()).doesNotThrowAnyException();
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5644) New DistributedReference JUnit rule for DistributedTests
[
https://issues.apache.org/jira/browse/GEODE-5644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-5644:
-
Description:
I'd like to add a new DistributedReference JUnit rule for DistributedTests
which would be used similar to an AtomicReference but with a reference that is
useable within every DUnit VM.
The idea is that this would allow us to define something like:
{noformat}
@Rule
public DistributedReference cacheReference = new
DistributedReference<>();
@Before
public void setUp() {
getVM(0).invoke(() -> cacheReference.set(new CacheFactory().create());
}
@After
public void tearDown() {
getVM(0).invoke(() -> cacheReference.get().close());
}
{noformat}
Each DUnit VM would have its own instance of Cache (or other type) available to
set and get with this rule.
This enables us to the Geode APIs directly within a test without depending on
more complex custom rules like CacheRule or ClusterStarterRule. This would make
tests that use it more directly dependent on the User APIs and force us to
become more aware of of the shortcomings of that API including its defaults. If
the Geode User APIs for creating and closing Cache is so difficult or verbose
to use or has the wrong defaults, then this will encourage us to fix the Geode
User API instead of hiding it behind complex custom rules that act as an API
Adapter layer.
We could also consider adding support for java.io.Closeable since resources
such as Cache implement Closeable. This would then obviate the need to
implement @After in most cases.
was:
I'd like to add a new DistributedReference JUnit rule for DistributedTests
which would be used similar to an AtomicReference but with a reference that is
useable within every DUnit VM.
The idea is that this would allow us to define something like:
{noformat}
@Rule
public DistributedReference cacheReference = new
DistributedReference<>();
@Before
public void setUp() {
getVM(0).invoke(() -> cacheReference.set(new CacheFactory().create());
}
@After
public void tearDown() {
getVM(0).invoke(() -> cacheReference.get().close());
}
{noformat}
Each DUnit VM would have its own instance of Cache (or other type) available to
set and get with this rule.
This enables us to the Geode APIs directly within a test without depending on
more complex custom rules like CacheRule or ClusterStarterRule. This would make
tests that use it more directly dependent on the User APIs and force us to
become more aware of of the shortcomings of that API including its defaults. If
the Geode User APIs for creating and closing Cache is so difficult or verbose
to use or has the wrong defaults, then this will encourage us to fix the Geode
User API instead of hiding it behind complex custom rules that act as an API
Adapter layer.
We could also consider adding support for java.io.Closeable since resources
such as Cache implement Closeable.
> New DistributedReference JUnit rule for DistributedTests
>
>
> Key: GEODE-5644
> URL: https://issues.apache.org/jira/browse/GEODE-5644
> Project: Geode
> Issue Type: Wish
> Components: tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
>
> I'd like to add a new DistributedReference JUnit rule for DistributedTests
> which would be used similar to an AtomicReference but with a reference that
> is useable within every DUnit VM.
> The idea is that this would allow us to define something like:
> {noformat}
> @Rule
> public DistributedReference cacheReference = new
> DistributedReference<>();
> @Before
> public void setUp() {
> getVM(0).invoke(() -> cacheReference.set(new CacheFactory().create());
> }
> @After
> public void tearDown() {
> getVM(0).invoke(() -> cacheReference.get().close());
> }
> {noformat}
> Each DUnit VM would have its own instance of Cache (or other type) available
> to set and get with this rule.
> This enables us to the Geode APIs directly within a test without depending on
> more complex custom rules like CacheRule or ClusterStarterRule. This would
> make tests that use it more directly dependent on the User APIs and force us
> to become more aware of of the shortcomings of that API including its
> defaults. If the Geode User APIs for creating and closing Cache is so
> difficult or verbose to use or has the wrong defaults, then this will
> encourage us to fix the Geode User API instead of hiding it behind complex
> custom rules that act as an API Adapter layer.
> We could also consider adding support for java.io.Closeable since resources
> such as Cache implement Closeable. This would then obviate the need to
> implement @After in most cases.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5644) New DistributedReference JUnit rule for DistributedTests
[
https://issues.apache.org/jira/browse/GEODE-5644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-5644:
-
Description:
I'd like to add a new DistributedReference JUnit rule for DistributedTests
which would be used similar to an AtomicReference but with a reference that is
useable within every DUnit VM.
The idea is that this would allow us to define something like:
{noformat}
@Rule
public DistributedReference cacheReference = new
DistributedReference<>();
@Before
public void setUp() {
getVM(0).invoke(() -> cacheReference.set(new CacheFactory().create());
}
@After
public void tearDown() {
getVM(0).invoke(() -> cacheReference.get().close());
}
{noformat}
Each DUnit VM would have its own instance of Cache (or other type) available to
set and get with this rule.
This enables us to the Geode APIs directly within a test without depending on
more complex custom rules like CacheRule or ClusterStarterRule. This would make
tests that use it more directly dependent on the User APIs and force us to
become more aware of of the shortcomings of that API including its defaults. If
the Geode User APIs for creating and closing Cache is so difficult or verbose
to use or has the wrong defaults, then this will encourage us to fix the Geode
User API instead of hiding it behind complex custom rules that act as an API
Adapter layer.
We could also consider adding support for java.io.Closeable since resources
such as Cache implement Closeable.
was:
I'd like to add a new DistributedReference JUnit rule for DistributedTests
which would be used similar to an AtomicReference but with a reference that is
useable within every DUnit VM.
The idea is that this would allow us to define something like:
{noformat}
@Rule
public DistributedReference cacheReference = new
DistributedReference<>();
@Before
public void setUp() {
getVM(0).invoke(() -> cacheReference.set(new CacheFactory().create());
}
@After
public void tearDown() {
getVM(0).invoke(() -> cacheReference.get().close());
}
{noformat}
Each DUnit VM would have its own instance of Cache (or other type) available to
set and get with this rule.
This enables us to the Geode APIs directly within a test without depending on
more complex custom rules like CacheRule or ClusterStarterRule. This would make
tests that use it more directly dependent on the User APIs and force us to
become more aware of of the shortcomings of that API. If the Geode User APIs
for creating and closing Cache is so difficult or verbose to use, then this
will encourage us to fix the Geode User API instead of hiding it behind complex
custom rules that act as an API Adapter layer.
We could also consider adding support for java.io.Closeable since resources
such as Cache implement Closeable.
> New DistributedReference JUnit rule for DistributedTests
>
>
> Key: GEODE-5644
> URL: https://issues.apache.org/jira/browse/GEODE-5644
> Project: Geode
> Issue Type: Wish
> Components: tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
>
> I'd like to add a new DistributedReference JUnit rule for DistributedTests
> which would be used similar to an AtomicReference but with a reference that
> is useable within every DUnit VM.
> The idea is that this would allow us to define something like:
> {noformat}
> @Rule
> public DistributedReference cacheReference = new
> DistributedReference<>();
> @Before
> public void setUp() {
> getVM(0).invoke(() -> cacheReference.set(new CacheFactory().create());
> }
> @After
> public void tearDown() {
> getVM(0).invoke(() -> cacheReference.get().close());
> }
> {noformat}
> Each DUnit VM would have its own instance of Cache (or other type) available
> to set and get with this rule.
> This enables us to the Geode APIs directly within a test without depending on
> more complex custom rules like CacheRule or ClusterStarterRule. This would
> make tests that use it more directly dependent on the User APIs and force us
> to become more aware of of the shortcomings of that API including its
> defaults. If the Geode User APIs for creating and closing Cache is so
> difficult or verbose to use or has the wrong defaults, then this will
> encourage us to fix the Geode User API instead of hiding it behind complex
> custom rules that act as an API Adapter layer.
> We could also consider adding support for java.io.Closeable since resources
> such as Cache implement Closeable.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5644) New DistributedReference JUnit rule for DistributedTests
[
https://issues.apache.org/jira/browse/GEODE-5644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-5644:
-
Description:
I'd like to add a new DistributedReference JUnit rule for DistributedTests
which would be used similar to an AtomicReference but with a reference that is
useable within every DUnit VM.
The idea is that this would allow us to define something like:
{noformat}
@Rule
public DistributedReference cacheReference = new
DistributedReference<>();
@Before
public void setUp() {
getVM(0).invoke(() -> cacheReference.set(new CacheFactory().create());
}
@After
public void tearDown() {
getVM(0).invoke(() -> cacheReference.get().close());
}
{noformat}
Each DUnit VM would have its own instance of Cache (or other type) available to
set and get with this rule.
This enables us to the Geode APIs directly within a test without depending on
more complex custom rules like CacheRule or ClusterStarterRule. This would make
tests that use it more directly dependent on the User APIs and force us to
become more aware of of the shortcomings of that API. If the Geode User APIs
for creating and closing Cache is so difficult or verbose to use, then this
will encourage us to fix the Geode User API instead of hiding it behind complex
custom rules that act as an API Adapter layer.
We could also consider adding support for java.io.Closeable since resources
such as Cache implement Closeable.
was:
I'd like to add a new DistributedReference JUnit rule for DistributedTests
which would be used similar to an AtomicReference but with a reference that is
useable within every DUnit VM.
The idea is that this would allow us to define something like:
{noformat}
@Rule
public DistributedReference cacheReference = new
DistributedReference<>();
@Before
public void setUp() {
getVM(0).invoke(() -> cacheReference.set(new CacheFactory().create());
}
@After
public void tearDown() {
getVM(0).invoke(() -> cacheReference.get().close());
}
{noformat}
And then use the Geode APIs directly within the test without relying on any
custom rules like CacheRule or ClusterStarterRule. This would make tests that
use it more directly dependent on the User APIs and force us to become more
aware of of the shortcomings of that API. If the Geode User API for creating
and closing Cache is so difficult or verbose to use, then this will encourage
us to fix the Geode User API instead of hiding it behind complex JUnit rules.
We could also consider adding support for java.io.Closeable since resources
such as Cache implement Closeable.
> New DistributedReference JUnit rule for DistributedTests
>
>
> Key: GEODE-5644
> URL: https://issues.apache.org/jira/browse/GEODE-5644
> Project: Geode
> Issue Type: Wish
> Components: tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
>
> I'd like to add a new DistributedReference JUnit rule for DistributedTests
> which would be used similar to an AtomicReference but with a reference that
> is useable within every DUnit VM.
> The idea is that this would allow us to define something like:
> {noformat}
> @Rule
> public DistributedReference cacheReference = new
> DistributedReference<>();
> @Before
> public void setUp() {
> getVM(0).invoke(() -> cacheReference.set(new CacheFactory().create());
> }
> @After
> public void tearDown() {
> getVM(0).invoke(() -> cacheReference.get().close());
> }
> {noformat}
> Each DUnit VM would have its own instance of Cache (or other type) available
> to set and get with this rule.
> This enables us to the Geode APIs directly within a test without depending on
> more complex custom rules like CacheRule or ClusterStarterRule. This would
> make tests that use it more directly dependent on the User APIs and force us
> to become more aware of of the shortcomings of that API. If the Geode User
> APIs for creating and closing Cache is so difficult or verbose to use, then
> this will encourage us to fix the Geode User API instead of hiding it behind
> complex custom rules that act as an API Adapter layer.
> We could also consider adding support for java.io.Closeable since resources
> such as Cache implement Closeable.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-5644) New DistributedReference JUnit rule for DistributedTests
[
https://issues.apache.org/jira/browse/GEODE-5644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund reassigned GEODE-5644:
Assignee: Kirk Lund
> New DistributedReference JUnit rule for DistributedTests
>
>
> Key: GEODE-5644
> URL: https://issues.apache.org/jira/browse/GEODE-5644
> Project: Geode
> Issue Type: Wish
> Components: tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
>
> I'd like to add a new DistributedReference JUnit rule for DistributedTests
> which would be used similar to an AtomicReference but with a reference that
> is useable within every DUnit VM.
> The idea is that this would allow us to define something like:
> {noformat}
> @Rule
> public DistributedReference cacheReference = new
> DistributedReference<>();
> @Before
> public void setUp() {
> getVM(0).invoke(() -> cacheReference.set(new CacheFactory().create());
> }
> @After
> public void tearDown() {
> getVM(0).invoke(() -> cacheReference.get().close());
> }
> {noformat}
> And then use the Geode APIs directly within the test without relying on any
> custom rules like CacheRule or ClusterStarterRule. This would make tests that
> use it more directly dependent on the User APIs and force us to become more
> aware of of the shortcomings of that API. If the Geode User API for creating
> and closing Cache is so difficult or verbose to use, then this will encourage
> us to fix the Geode User API instead of hiding it behind complex JUnit rules.
> We could also consider adding support for java.io.Closeable since resources
> such as Cache implement Closeable.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-5644) New DistributedReference JUnit rule for DistributedTests
Kirk Lund created GEODE-5644:
Summary: New DistributedReference JUnit rule for DistributedTests
Key: GEODE-5644
URL: https://issues.apache.org/jira/browse/GEODE-5644
Project: Geode
Issue Type: Wish
Components: tests
Reporter: Kirk Lund
I'd like to add a new DistributedReference JUnit rule for DistributedTests
which would be used similar to an AtomicReference but with a reference that is
useable within every DUnit VM.
The idea is that this would allow us to define something like:
{noformat}
@Rule
public DistributedReference cacheReference = new
DistributedReference<>();
@Before
public void setUp() {
getVM(0).invoke(() -> cacheReference.set(new CacheFactory().create());
}
@After
public void tearDown() {
getVM(0).invoke(() -> cacheReference.get().close());
}
{noformat}
And then use the Geode APIs directly within the test without relying on any
custom rules like CacheRule or ClusterStarterRule. This would make tests that
use it more directly dependent on the User APIs and force us to become more
aware of of the shortcomings of that API. If the Geode User API for creating
and closing Cache is so difficult or verbose to use, then this will encourage
us to fix the Geode User API instead of hiding it behind complex JUnit rules.
We could also consider adding support for java.io.Closeable since resources
such as Cache implement Closeable.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-5643) Use of dependency-version.properties as string variables obfuscates dependency version information from nebula lint plugin
Patrick Rhomberg created GEODE-5643:
---
Summary: Use of dependency-version.properties as string variables
obfuscates dependency version information from nebula lint plugin
Key: GEODE-5643
URL: https://issues.apache.org/jira/browse/GEODE-5643
Project: Geode
Issue Type: Improvement
Components: build
Reporter: Patrick Rhomberg
According to the gradle documentation [1], the preferred pattern for defining
version dependencies is to (a) not include version information in
{noformat}implementation {noformat} directives, and to (b)
constrain the version in a single {noformat}constraints {noformat}
block.
Furthermore, our consumption of explicit versions in each {{implementation}}
block conflicts with the nebula dependency link checker, which expect this best
practice.
[1]
https://docs.gradle.org/current/userguide/managing_transitive_dependencies.html
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-5643) Use of dependency-version.properties as string variables obfuscates dependency version information from nebula lint plugin
[
https://issues.apache.org/jira/browse/GEODE-5643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg reassigned GEODE-5643:
---
Assignee: Patrick Rhomberg
> Use of dependency-version.properties as string variables obfuscates
> dependency version information from nebula lint plugin
> --
>
> Key: GEODE-5643
> URL: https://issues.apache.org/jira/browse/GEODE-5643
> Project: Geode
> Issue Type: Improvement
> Components: build
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>Priority: Major
>
> According to the gradle documentation [1], the preferred pattern for defining
> version dependencies is to (a) not include version information in
> {noformat}implementation {noformat} directives, and to (b)
> constrain the version in a single {noformat}constraints {noformat}
> block.
> Furthermore, our consumption of explicit versions in each {{implementation}}
> block conflicts with the nebula dependency link checker, which expect this
> best practice.
> [1]
> https://docs.gradle.org/current/userguide/managing_transitive_dependencies.html
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-5496) Create a reaper pipeline
[ https://issues.apache.org/jira/browse/GEODE-5496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Rhomberg resolved GEODE-5496. - Resolution: Fixed > Create a reaper pipeline > > > Key: GEODE-5496 > URL: https://issues.apache.org/jira/browse/GEODE-5496 > Project: Geode > Issue Type: Task >Reporter: Finn Southerland >Priority: Major > Labels: pull-request-available > Time Spent: 1h > Remaining Estimate: 0h > > We should shut down pipeline-created instances after a certain period if they > do not get shut down for some reason. An additional concourse pipeline can do > this. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-5600) Property file creation occurs any time .git/index is updated (which is all the time)
[
https://issues.apache.org/jira/browse/GEODE-5600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg resolved GEODE-5600.
-
Resolution: Fixed
Fix Version/s: 1.8.0
> Property file creation occurs any time .git/index is updated (which is all
> the time)
>
>
> Key: GEODE-5600
> URL: https://issues.apache.org/jira/browse/GEODE-5600
> Project: Geode
> Issue Type: Improvement
> Components: build
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.8.0
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Because the property file is an input for the {{jar}} target, this causes a
> significant increase in build time, even when nothing significant has changed.
>
> As a standard development cycle, regeneration of the property file should be
> optional / skipped.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5641) DiskDirRule should have a public no-arg constructor
[
https://issues.apache.org/jira/browse/GEODE-5641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-5641:
--
Labels: pull-request-available (was: )
> DiskDirRule should have a public no-arg constructor
> ---
>
> Key: GEODE-5641
> URL: https://issues.apache.org/jira/browse/GEODE-5641
> Project: Geode
> Issue Type: Wish
> Components: tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Labels: pull-request-available
>
> DiskDirRule should have a public no-arg constructor for this usage:
> {noformat}
> @Rule
> public DiskDirRule diskDirRule = new DiskDirRule();
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5642) cleanAll task is no longer necessary
[ https://issues.apache.org/jira/browse/GEODE-5642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-5642: -- Labels: pull-request-available (was: ) > cleanAll task is no longer necessary > > > Key: GEODE-5642 > URL: https://issues.apache.org/jira/browse/GEODE-5642 > Project: Geode > Issue Type: Task > Components: build >Reporter: Finn Southerland >Priority: Major > Labels: pull-request-available > > Because the project structure has changed, we no longer need a custom > 'cleanAll' task to delete the root build directory. We should remove it. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-3505) NonBlockingProcessStreamReaderIntegrationTest.processTerminatesWhenDestroyed fails intermittently with ConditionTimeoutException
[
https://issues.apache.org/jira/browse/GEODE-3505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
nabarun updated GEODE-3505:
---
Fix Version/s: (was: 1.8.0)
1.7.0
> NonBlockingProcessStreamReaderIntegrationTest.processTerminatesWhenDestroyed
> fails intermittently with ConditionTimeoutException
>
>
> Key: GEODE-3505
> URL: https://issues.apache.org/jira/browse/GEODE-3505
> Project: Geode
> Issue Type: Bug
> Components: gfsh, management, tests
> Environment: AWS
>Reporter: Kirk Lund
>Priority: Major
> Labels: Flaky, swat
> Fix For: 1.7.0
>
>
> {noformat}
> org.apache.geode.internal.process.NonBlockingProcessStreamReaderIntegrationTest
> > processTerminatesWhenDestroyed FAILED
> org.awaitility.core.ConditionTimeoutException: Condition defined as a
> lambda expression in
> org.apache.geode.internal.process.AbstractProcessStreamReaderIntegrationTest
> expected:<[fals]e> but was:<[tru]e> within 2 milliseconds.
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-1866) SUPERFLAKY: LauncherLifecycleCommandsDUnitTest.test014GemFireServerJvmProcessTerminatesOnOutOfMemoryError
[
https://issues.apache.org/jira/browse/GEODE-1866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
nabarun updated GEODE-1866:
---
Fix Version/s: (was: 1.8.0)
1.7.0
> SUPERFLAKY:
> LauncherLifecycleCommandsDUnitTest.test014GemFireServerJvmProcessTerminatesOnOutOfMemoryError
> -
>
> Key: GEODE-1866
> URL: https://issues.apache.org/jira/browse/GEODE-1866
> Project: Geode
> Issue Type: Bug
> Components: management
>Reporter: xiaojian zhou
>Assignee: Helena Bales
>Priority: Major
> Labels: CI, flaky, swat
> Fix For: 1.7.0
>
>
> {noformat}
> Geode_develop_DistributedTests 3832
> one of failures is:
> com.gemstone.gemfire.management.internal.cli.commands.LauncherLifecycleCommandsDUnitTest
> > test006StartLocatorInRelativeDirectory FAILED
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertTrue(Assert.java:52)
> at
> com.gemstone.gemfire.management.internal.cli.commands.LauncherLifecycleCommandsDUnitTest.readPid(LauncherLifecycleCommandsDUnitTest.java:175)
> at
> com.gemstone.gemfire.management.internal.cli.commands.LauncherLifecycleCommandsDUnitTest.waitForGemFireProcessToStop(LauncherLifecycleCommandsDUnitTest.java:240)
> at
> com.gemstone.gemfire.management.internal.cli.commands.LauncherLifecycleCommandsDUnitTest.stopLocator(LauncherLifecycleCommandsDUnitTest.java:210)
> at
> com.gemstone.gemfire.management.internal.cli.commands.LauncherLifecycleCommandsDUnitTest.stopLocator(LauncherLifecycleCommandsDUnitTest.java:206)
> at
> com.gemstone.gemfire.management.internal.cli.commands.LauncherLifecycleCommandsDUnitTest.test006StartLocatorInRelativeDirectory(LauncherLifecycleCommandsDUnitTest.java:492)
> [noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-1357) Cleanup Category inclusion/exclusion in test.gradle
[ https://issues.apache.org/jira/browse/GEODE-1357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] nabarun updated GEODE-1357: --- Fix Version/s: (was: 1.8.0) 1.7.0 > Cleanup Category inclusion/exclusion in test.gradle > --- > > Key: GEODE-1357 > URL: https://issues.apache.org/jira/browse/GEODE-1357 > Project: Geode > Issue Type: Improvement > Components: build >Reporter: Kirk Lund >Priority: Major > Fix For: 1.7.0 > > > The file patterns and Category inclusion/exclusion definitions of each test > task in test.gradle should be simplified. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-4336) Geode Native C++ Example (OQL)
[ https://issues.apache.org/jira/browse/GEODE-4336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] nabarun updated GEODE-4336: --- Fix Version/s: (was: 1.8.0) 1.7.0 > Geode Native C++ Example (OQL) > -- > > Key: GEODE-4336 > URL: https://issues.apache.org/jira/browse/GEODE-4336 > Project: Geode > Issue Type: Sub-task > Components: native client >Reporter: Addison >Assignee: Dave Barnes >Priority: Major > Labels: pull-request-available > Fix For: 1.7.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-3530) All DistributedTests that extend CliCommandTestBase are Flaky
[ https://issues.apache.org/jira/browse/GEODE-3530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] nabarun updated GEODE-3530: --- Fix Version/s: (was: 1.8.0) 1.7.0 > All DistributedTests that extend CliCommandTestBase are Flaky > - > > Key: GEODE-3530 > URL: https://issues.apache.org/jira/browse/GEODE-3530 > Project: Geode > Issue Type: Bug > Components: management, tests >Reporter: Kirk Lund >Assignee: Helena Bales >Priority: Major > Labels: CliCommandTestBase, DistributedTest, Flaky, > pull-request-available, swat > Fix For: 1.7.0 > > Time Spent: 6h 40m > Remaining Estimate: 0h > > All DistributedTests that extend CliCommandTestBase are Flaky. The tests need > to be rewritten with GfshShellConnectionRule so we can delete > CliCommandTestBase. > List of test classes extending CliCommandTestBase and existing Flaky tickets: > * -AlterRegionCommandDUnitTest- (GEODE-3018) > * -ClusterConfigurationDUnitTest- (GEODE-1333, GEODE-1334) > * -ConfigCommandsDUnitTest- (GEODE-1449) > * -ConnectCommandWithHttpAndSSLDUnitTest- > * -CreateAlterDestroyRegionCommandsDUnitTest- (GEODE-973, GEODE-2009, > GEODE-3018) > * -CreateRegionCommandDUnitTest- (GEODE-973) > * -DescribeClientCommandDUnitTest- (GEODE-910) > * -DestroyRegionCommandDUnitTest- > * -DiskStoreCommandsDUnitTest- (GEODE-1206, GEODE-1406, GEODE-2102) > * -DurableClientCommandsDUnitTest- (GEODE-1705, GEODE-3404, GEODE-3359) > * -FunctionCommandsDUnitTest- (GEODE-1563) > * -GemfireDataCommandsDUnitTest- (GEODE-1182, GEODE-1249, GEODE-1404, > GEODE-1430, GEODE-1487, GEODE-1496, GEODE-1561, GEODE-1822, GEODE-2006) > * -GetCommandOnRegionWithCacheLoaderDuringCacheMissDUnitTest- (Does not > exist) > * LauncherLifecycleCommandsDUnitTest > * -ListAndDescribeDiskStoreCommandsDUnitTest (does not exist)- > * -ListClientCommandDUnitTest- (GEODE-908) (Jinmei/Finn) > * -ListIndexCommandDUnitTest- > * -LuceneIndexCommandsDUnitTest- (does not exist) > * -MiscellaneousCommandsDUnitTest (GEODE-1034, GEODE-1385, GEODE-1518, > GEODE-1605, GEODE-1706, GEODE-2126)- > * -QueueCommandsDUnitTest- (does not exist) (GEODE-1429, GEODE-1976) > * -RebalanceCommandDistributedTest- (Finn) > * -RebalanceCommandOverHttpDistributedTest- (Finn) > * -ShellCommandsDUnitTest- (GEODE-989) > * -ShowMetricsDUnitTest- (GEODE-1764) > * -ShowStackTraceDUnitTest- (does not exist) > * -WANCommandTestBase- (and subclasses) > * -ClientCommandsTestUtils- > * -ShellCommandsDUnitTest- (Jinmei) > Test classes that *use* but do not extend CliCommandTestBase: > * CommandOverrHttpDUnitTest -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-4593) MigrationClient and MigrationServer classes should be removed
[ https://issues.apache.org/jira/browse/GEODE-4593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] nabarun updated GEODE-4593: --- Fix Version/s: (was: 1.8.0) 1.7.0 > MigrationClient and MigrationServer classes should be removed > - > > Key: GEODE-4593 > URL: https://issues.apache.org/jira/browse/GEODE-4593 > Project: Geode > Issue Type: Improvement > Components: core >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Labels: pull-request-available > Fix For: 1.7.0 > > Time Spent: 20m > Remaining Estimate: 0h > > The MigrationClient and MigrationServer classes in org.apache.geode.internal > are no longer used and should be removed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-4614) PutMessage.toData throws NPE if cache has started closing
[
https://issues.apache.org/jira/browse/GEODE-4614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
nabarun updated GEODE-4614:
---
Fix Version/s: (was: 1.8.0)
1.7.0
> PutMessage.toData throws NPE if cache has started closing
> -
>
> Key: GEODE-4614
> URL: https://issues.apache.org/jira/browse/GEODE-4614
> Project: Geode
> Issue Type: Bug
> Components: messaging
>Reporter: Galen O'Sullivan
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.7.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> This is from a failure in CI. I'm pretty sure it was caused by a PutMessage
> being sent after PartitionedRegion.prIdToPR was cleared on Cache close. This
> causes the message to throw a NullPointerException, which eventually results
> in a CacheClosedException.
> One problem is that this message is getting access to the Region to increment
> some stats -- that should probably be done at a higher level. Another problem
> is that we use this static map rather than holding a reference to the Region
> itself.
> {code:none}
> [warning 2018/01/30 15:30:35.543 PST
> bridgegemfire6_rs-FullRegression-2018-01-29-17-49-20-client-19_2013
> tid=0xee] Server connection from
> [identity(rs-FullRegression-2018-01-29-17-49-20-client-19(edgegemfire1_rs-FullRegression-2018-01-29-17-49-20-client-19_2055:2055:loner):42782:6bcd6549:edgegemfire1_rs-FullRegression-2018-01-29-17-49-20-client-19_2055,connection=1;
> port=45552]: Unexpected Exception
> org.apache.geode.cache.CacheClosedException: The cache is closed., caused by
> org.apache.geode.ToDataException: toData failed on DataSerializable class
> org.apache.geode.internal.cache.partitioned.PutMessage
> at
> org.apache.geode.internal.cache.GemFireCacheImpl$Stopper.generateCancelledException(GemFireCacheImpl.java:1527)
> at
> org.apache.geode.CancelCriterion.checkCancelInProgress(CancelCriterion.java:83)
> at
> org.apache.geode.internal.cache.tier.CachedRegionHelper.checkCancelInProgress(CachedRegionHelper.java:38)
> at
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.checkForInterrupt(BaseCommand.java:690)
> at
> org.apache.geode.internal.cache.tier.sockets.command.Put65.cmdExecute(Put65.java:430)
> at
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:163)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMsg(ServerConnection.java:797)
> at
> org.apache.geode.internal.cache.tier.sockets.LegacyServerConnection.doOneMessage(LegacyServerConnection.java:85)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1177)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl$4$1.run(AcceptorImpl.java:638)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: org.apache.geode.ToDataException: toData failed on
> DataSerializable class org.apache.geode.internal.cache.partitioned.PutMessage
> at
> org.apache.geode.internal.InternalDataSerializer.invokeToData(InternalDataSerializer.java:2421)
> at
> org.apache.geode.internal.InternalDataSerializer.writeDSFID(InternalDataSerializer.java:1499)
> at
> org.apache.geode.internal.tcp.MsgStreamer.writeMessage(MsgStreamer.java:233)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:378)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:238)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:604)
> at
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.directChannelSend(GMSMembershipManager.java:1715)
> at
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.send(GMSMembershipManager.java:1905)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:3224)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:3139)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendMessage(ClusterDistributionManager.java:3177)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.putOutgoing(ClusterDistributionManager.java:1706)
> at
> org.apache.geode.internal.cache.partitioned.PutMessage.send(PutMessage.java:386)
> at
> org.apache.geode.internal.cache.PartitionedRegion.putRemotely(PartitionedRegion.java:3185)
>
[jira] [Updated] (GEODE-4965) Add security permissions to documentation for JNDI binding commands
[ https://issues.apache.org/jira/browse/GEODE-4965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] nabarun updated GEODE-4965: --- Fix Version/s: (was: 1.8.0) 1.7.0 > Add security permissions to documentation for JNDI binding commands > --- > > Key: GEODE-4965 > URL: https://issues.apache.org/jira/browse/GEODE-4965 > Project: Geode > Issue Type: Task > Components: docs >Reporter: Barbara Pruijn >Assignee: Karen Smoler Miller >Priority: Major > Labels: pull-request-available > Fix For: 1.7.0 > > Time Spent: 20m > Remaining Estimate: 0h > > The following commands need to be added to the permission list on these pages: > http://geode.apache.org/docs/guide/14/managing/security/implementing_authorization.html > https://cwiki.apache.org/confluence/display/GEODE/Geode+Integrated+Security > https://cwiki.apache.org/confluence/display/GEODE/Finer%20grained%20security > create jndi-binding: CLUSTER:MANAGE > list jndi-binding: CLUSTER:READ > describe jndi-binding: CLUSTER:READ > destroy jndi-binding: CLUSTER:MANAGE -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-4791) Update gradle version from 3.5.1 to 4.8
[ https://issues.apache.org/jira/browse/GEODE-4791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] nabarun updated GEODE-4791: --- Fix Version/s: (was: 1.8.0) 1.7.0 > Update gradle version from 3.5.1 to 4.8 > --- > > Key: GEODE-4791 > URL: https://issues.apache.org/jira/browse/GEODE-4791 > Project: Geode > Issue Type: Improvement > Components: build, general >Reporter: Udo Kohlmeyer >Assignee: Jens Deppe >Priority: Major > Labels: pull-request-available > Fix For: 1.7.0 > > Time Spent: 3h > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-5642) cleanAll task is no longer necessary
Finn Southerland created GEODE-5642: --- Summary: cleanAll task is no longer necessary Key: GEODE-5642 URL: https://issues.apache.org/jira/browse/GEODE-5642 Project: Geode Issue Type: Task Components: build Reporter: Finn Southerland Because the project structure has changed, we no longer need a custom 'cleanAll' task to delete the root build directory. We should remove it. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-4726) Documentation is misleading with a multi-homed Geode cluster
[
https://issues.apache.org/jira/browse/GEODE-4726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
nabarun updated GEODE-4726:
---
Fix Version/s: (was: 1.8.0)
1.7.0
> Documentation is misleading with a multi-homed Geode cluster
>
>
> Key: GEODE-4726
> URL: https://issues.apache.org/jira/browse/GEODE-4726
> Project: Geode
> Issue Type: Bug
> Components: configuration, docs
>Reporter: Kyle R Dunn
>Assignee: Karen Smoler Miller
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.7.0
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> The necessary step for binding Geode to an arbitrary network interface (e.g.
> {{eth2}}), is not clearly documented. A multi-homing scenario (i.e. several
> non-loopback NICs) is quite common.
> The {{server-bind-address=w.x.y.z}} parameter appears to have no effect on
> the interface used by the server process; however passing
> {{bind-address=w.x.y.z}} to the server startup produces the correct startup
> behavior. The documentation around this is a bit misleading.
> The symptom was a startup hang, ultimately timing out, like the following:
> {code:bash}
> [info 2018/02/22 13:13:29.134 MST server1 tid=0x1] Attempting to join
> the distributed system through coordinator
> 172.16.139.1(locator1:70192:locator):1024 using address
> 192.168.0.29(server1:70198):1024
> {code}
> The following script was used successfully on Mac OS to bind to the "last"
> interface listed by ifconfig (vmnet8).
> {code:bash}
> #!/bin/bash
> rm -rf locator1 server1
> export GEODE_HOME=/opt/pivotal-gemfire-9.3.0
> export CLASSPATH=${GEODE_HOME}/lib/gemfire-greenplum-3.1.1.jar
> gfsh < start locator --name=locator1 --locators=172.16.139.1[10334]
> --bind-address=172.16.139.1 --port=10334 --include-system-classpath
> start server --name=server1 --start-rest-api=true --http-service-port=28080
> --locators=172.16.139.1[10334] --bind-address=172.16.139.1
> --cache-xml-file=../config/ggc_cache.xml --classpath=${CLASSPATH}
> --include-system-classpath
> EOF
> {code}
> The contents of {{ggc_cache.xml}} is below.
> {code:xml}
>
> http://geode.apache.org/schema/cache;
> xmlns:gpdb="http://schema.pivotal.io/gemfire/gpdb;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://geode.apache.org/schema/cache
> http://geode.apache.org/schema/cache/cache-1.0.xsd
> http://schema.pivotal.io/gemfire/gpdb
> http://schema.pivotal.io/gemfire/gpdb/gpdb-2.4.xsd;
> version="1.0">
>
> disk-store-name="pdx_meta_data"/>
>
>
> jdbc-driver-class="org.postgresql.Driver" user-name="gpadmin"
> password="supersecret"
> connection-url="jdbc:postgresql://172.16.139.132:5432/gemfire_db">
>
>
>
>
>
>
>
> schema="public"
> table="cust_dim">
>
>
>class="java.lang.String" />
>
>
>
>
>
>
>
>
> eviction-heap-percentage="75"/>
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5157) ClientHealthStats may not be propagated when system has a hostname
[
https://issues.apache.org/jira/browse/GEODE-5157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
nabarun updated GEODE-5157:
---
Fix Version/s: (was: 1.8.0)
1.7.0
> ClientHealthStats may not be propagated when system has a hostname
> --
>
> Key: GEODE-5157
> URL: https://issues.apache.org/jira/browse/GEODE-5157
> Project: Geode
> Issue Type: Bug
> Components: cq, jmx
>Reporter: Jens Deppe
>Assignee: Helena Bales
>Priority: Major
> Fix For: 1.7.0
>
>
> For CQs, the client publishes stats from
> {{ClientStatsManager.publishClientStats}}. Here the client memberId is used
> as a key for putting the stats into an admin region. If the client has a
> valid hostname then the memberId contains the hostname. If there is no valid
> hostname, then the memberId is just the IP address.
> On the server side, clientIDs are determined from {{CacheClientProxy}}
> objects - see {{CacheServerBridge.getUniqueClientIds}}. It appears that these
> IDs are always IP-address based.
> Thus if there is this mismatch then ClientHealthStats are not published
> correctly.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5186) set operation in a client transaction could cause the transaction to hang
[
https://issues.apache.org/jira/browse/GEODE-5186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
nabarun updated GEODE-5186:
---
Fix Version/s: (was: 1.8.0)
1.7.0
> set operation in a client transaction could cause the transaction to hang
> -
>
> Key: GEODE-5186
> URL: https://issues.apache.org/jira/browse/GEODE-5186
> Project: Geode
> Issue Type: Bug
> Components: transactions
>Affects Versions: 1.1.0, 1.1.1, 1.2.0, 1.3.0, 1.2.1, 1.4.0, 1.5.0, 1.6.0,
> 1.7.0
>Reporter: Eric Shu
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.7.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> During an entry operation in a client transaction, server connection could be
> lost. In this case, client will failover to another server and try to resume
> the transaction and retry the operation if the original transaction host node
> is found.
> If this operation happens to be a keySet operation (or other set operations)
> on a partitioned region, the transaction could hang due to a deadlock.
> The scenario is the original tx host node holds its transactional lock when
> sending fetchKey request to other nodes hosting the partitioned region data.
> The node on which the client transaction failed over, will hold its
> transactional lock while sending the FetchKey message to transaction hosting
> node.
> These two FetchKeyMessage will not be able to be processed as processing
> these tx message requires to hold the lock. But the locks are already been
> held by the nodes handing the client message of the transaction.
> {noformat}
> vm_6_bridge7_latvia_25133:PartitionedRegion Message Processor10 ID=0xe2(226)
> state=WAITING
> waiting to lock
>
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)
> at
> java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:209)
> at
> java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285)
> at
> org.apache.geode.internal.cache.TXManagerImpl.getLock(TXManagerImpl.java:921)
> at
> org.apache.geode.internal.cache.TXManagerImpl.masqueradeAs(TXManagerImpl.java:881)
> at
> org.apache.geode.internal.cache.partitioned.PartitionMessage.process(PartitionMessage.java:332)
> at
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:378)
> at
> org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:444)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.runUntilShutdown(ClusterDistributionManager.java:1121)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.access$000(ClusterDistributionManager.java:109)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager$8$1.run(ClusterDistributionManager.java:945)
> at java.lang.Thread.run(Thread.java:745)
> Locked synchronizers:
> java.util.concurrent.ThreadPoolExecutor$Worker@c84d7d4
> vm_6_bridge7_latvia_25133:ServerConnection on port 23931 Thread 10
> ID=0x128(296) state=TIMED_WAITING
> waiting to lock
> at sun.misc.Unsafe.park(Native Method)
> at
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)
> at
> org.apache.geode.internal.util.concurrent.StoppableCountDownLatch.await(StoppableCountDownLatch.java:61)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.basicWait(ReplyProcessor21.java:715)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:790)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:766)
>
[jira] [Updated] (GEODE-5223) add unit tests for AbstractRegionMap.txApplyDestroy
[ https://issues.apache.org/jira/browse/GEODE-5223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] nabarun updated GEODE-5223: --- Fix Version/s: (was: 1.8.0) 1.7.0 > add unit tests for AbstractRegionMap.txApplyDestroy > --- > > Key: GEODE-5223 > URL: https://issues.apache.org/jira/browse/GEODE-5223 > Project: Geode > Issue Type: Improvement > Components: transactions >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: pull-request-available > Fix For: 1.7.0 > > Time Spent: 20m > Remaining Estimate: 0h > > The current unit test for AbstractRegionMap has no coverage of txApplyDestroy. > Before refactoring txApplyDestroy it should be under test. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5237) DiskAccessException can sometimes state that actual usage is less than critical
[ https://issues.apache.org/jira/browse/GEODE-5237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] nabarun updated GEODE-5237: --- Fix Version/s: (was: 1.8.0) 1.7.0 > DiskAccessException can sometimes state that actual usage is less than > critical > --- > > Key: GEODE-5237 > URL: https://issues.apache.org/jira/browse/GEODE-5237 > Project: Geode > Issue Type: Bug > Components: persistence >Reporter: Lynn Gallinat >Assignee: Lynn Gallinat >Priority: Major > Labels: pull-request-available > Fix For: 1.7.0 > > Time Spent: 20m > Remaining Estimate: 0h > > It's possible that GEODE can throw a DiskAccessException stating that the > current file system usage exceeds the critical threshold, but the exception's > message states that the file system usage is UNDER the critical threshold, as > follows. This appears to be only an error in what is logged and GEODE really > is over critical. > org.apache.geode.cache.DiskAccessException: For DiskStore: dmDiskStore_3604: > Critical disk usage threshold exceeded for volume > /var/vcap/data/scratch/serialParRegHABridgePersistParOffline-0516-200217/vm_2_bridge3_disk_1: > the file system is 5% full, which exceeds the critical threshold of > 5.203678%. > The problem is that GEODE rounds the file system usage before logging it in > the message in the method DiskUsage.update(float, float), and this can cause > the problem when it gets rounded down: > double use = 100.0 * (total - remaining) / total; > recordStats(total, remaining, elapsed); > String pct = Math.round(use) + "%"; <= -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5255) In a race condition, a colocated bucket may not be created during rebalance when member nodes are restarted
[ https://issues.apache.org/jira/browse/GEODE-5255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] nabarun updated GEODE-5255: --- Fix Version/s: (was: 1.8.0) 1.7.0 > In a race condition, a colocated bucket may not be created during rebalance > when member nodes are restarted > --- > > Key: GEODE-5255 > URL: https://issues.apache.org/jira/browse/GEODE-5255 > Project: Geode > Issue Type: Bug > Components: regions >Affects Versions: 1.1.0, 1.2.0, 1.3.0, 1.4.0, 1.5.0, 1.6.0, 1.7.0 >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: pull-request-available > Fix For: 1.7.0 > > Time Spent: 1.5h > Remaining Estimate: 0h > > During rebalance, a member node may request a newly started member node to > grab a bucket from a parent partitioned region based on its calculated model. > When the new member creates the parent bucket, it is required to grab the > bucket's colocated child buckets. If the colocated child bucket underlying > partitioned region is not yet initialized, the child bucket will not be > created on the member. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5267) User Guide - un-document deprecated JTA transaction manager
[ https://issues.apache.org/jira/browse/GEODE-5267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] nabarun updated GEODE-5267: --- Fix Version/s: (was: 1.8.0) 1.7.0 > User Guide - un-document deprecated JTA transaction manager > --- > > Key: GEODE-5267 > URL: https://issues.apache.org/jira/browse/GEODE-5267 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Major > Labels: pull-request-available > Fix For: 1.7.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > As of Geode 1.2, Geode’s JTA transaction manager is deprecated. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5249) need test methods to display content of serial gateway sender queue
[ https://issues.apache.org/jira/browse/GEODE-5249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] nabarun updated GEODE-5249: --- Fix Version/s: (was: 1.8.0) 1.7.0 > need test methods to display content of serial gateway sender queue > --- > > Key: GEODE-5249 > URL: https://issues.apache.org/jira/browse/GEODE-5249 > Project: Geode > Issue Type: New Feature > Components: wan >Reporter: xiaojian zhou >Priority: Major > Labels: pull-request-available > Fix For: 1.7.0 > > Time Spent: 1h > Remaining Estimate: 0h > > We have method to display Parallel Gateway Sender Queue's content. We need > the same thing for serial gateway sender queue. > > Also we need to display the content for unprocessedEvents and > unprocessedTokens. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5269) CommitConflictException after TransactionInDoubtException
[
https://issues.apache.org/jira/browse/GEODE-5269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
nabarun updated GEODE-5269:
---
Fix Version/s: (was: 1.8.0)
1.7.0
> CommitConflictException after TransactionInDoubtException
> -
>
> Key: GEODE-5269
> URL: https://issues.apache.org/jira/browse/GEODE-5269
> Project: Geode
> Issue Type: Test
> Components: client/server, transactions
>Reporter: Bruce Schuchardt
>Assignee: Bruce Schuchardt
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.7.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> If a client initiates a transaction commit and gets a
> TransactionInDoubtException because the server hosting the transaction is
> shutting down the client can easily get a CommitConflictException if it
> attempts another transaction using one or more of the same keys as the
> in-doubt transaction.
> {noformat}
> org.apache.geode.cache.CommitConflictException: Concurrent transaction commit
> detected The key Object_130 in region /testRegion was being modified by
> another transaction locally. org.apache.geode.cache.CommitConflictException:
> Concurrent transaction commit detected The key Object_130 in region
> /testRegion was being modified by another transaction locally.
> at
> org.apache.geode.internal.cache.locks.TXLockServiceImpl.txLock(TXLockServiceImpl.java:137)
> at
> org.apache.geode.internal.cache.TXLockRequest.obtain(TXLockRequest.java:88)
> at
> org.apache.geode.internal.cache.TXState.reserveAndCheck(TXState.java:335)
> at org.apache.geode.internal.cache.TXState.commit(TXState.java:406)
> at
> org.apache.geode.internal.cache.TXStateProxyImpl.commit(TXStateProxyImpl.java:226)
> at
> org.apache.geode.internal.cache.TXManagerImpl.commit(TXManagerImpl.java:405)
> at
> org.apache.geode.internal.cache.tier.sockets.command.CommitCommand.cmdExecute(CommitCommand.java:82)
> at
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:158)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMsg(ServerConnection.java:869)
> at
> org.apache.geode.internal.cache.tier.sockets.OriginalServerConnection.doOneMessage(OriginalServerConnection.java:77)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1248)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl$4$1.run(AcceptorImpl.java:644)
> at java.lang.Thread.run(Thread.java:748)
> util.TestException: Unexpected
> org.apache.geode.cache.CommitConflictException: Concurrent transaction commit
> detected The key Object_130 in region /testRegion was being modified by
> another transaction locally. org.apache.geode.cache.CommitConflictException:
> Concurrent transaction commit detected The key Object_130 in region
> /testRegion was being modified by another transaction locally.
> at
> org.apache.geode.internal.cache.locks.TXLockServiceImpl.txLock(TXLockServiceImpl.java:137)
> at
> org.apache.geode.internal.cache.TXLockRequest.obtain(TXLockRequest.java:88)
> at
> org.apache.geode.internal.cache.TXState.reserveAndCheck(TXState.java:335)
> at org.apache.geode.internal.cache.TXState.commit(TXState.java:406)
> at
> org.apache.geode.internal.cache.TXStateProxyImpl.commit(TXStateProxyImpl.java:226)
> at
> org.apache.geode.internal.cache.TXManagerImpl.commit(TXManagerImpl.java:405)
> at
> org.apache.geode.internal.cache.tier.sockets.command.CommitCommand.cmdExecute(CommitCommand.java:82)
> at
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:158)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMsg(ServerConnection.java:869)
> at
> org.apache.geode.internal.cache.tier.sockets.OriginalServerConnection.doOneMessage(OriginalServerConnection.java:77)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1248)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl$4$1.run(AcceptorImpl.java:644)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> This is apparently due to the hosting server still being around and holding
> the locks. If you wait for a bit and then try the
[jira] [Updated] (GEODE-5265) PartitionedRegionStats dataStoreEntryCount can go negative
[ https://issues.apache.org/jira/browse/GEODE-5265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] nabarun updated GEODE-5265: --- Fix Version/s: (was: 1.8.0) 1.7.0 > PartitionedRegionStats dataStoreEntryCount can go negative > -- > > Key: GEODE-5265 > URL: https://issues.apache.org/jira/browse/GEODE-5265 > Project: Geode > Issue Type: Bug > Components: regions >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: pull-request-available > Fix For: 1.7.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > The statistic dataStoreEntryCount on PartitionedRegionStats is supposed to be > the number of entries in a partitioned region stored in a member. So it > should never be negative. > But in some cases it is decremented more than once when an entry is removed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5270) Close the input stream when closing connection.
[ https://issues.apache.org/jira/browse/GEODE-5270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] nabarun updated GEODE-5270: --- Fix Version/s: (was: 1.8.0) 1.7.0 > Close the input stream when closing connection. > --- > > Key: GEODE-5270 > URL: https://issues.apache.org/jira/browse/GEODE-5270 > Project: Geode > Issue Type: Bug > Components: wan >Reporter: nabarun >Assignee: nabarun >Priority: Major > Labels: pull-request-available > Fix For: 1.7.0 > > Time Spent: 40m > Remaining Estimate: 0h > > Issue: If the gateway stomper thread is activated while a dispatcher > activates a ackReadThread, they both may end up reading the on the same > connection, resulting in reading wrong header and causing out of memory > issues by allocating wrong memory. > Fix: > Close the input streams before closing the connection and also shutdown any > AckThreadReaders operating on the connection. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5273) ForceReattemptException must not be wrapped in another ForceReattemptException
[ https://issues.apache.org/jira/browse/GEODE-5273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] nabarun updated GEODE-5273: --- Fix Version/s: (was: 1.8.0) 1.7.0 > ForceReattemptException must not be wrapped in another ForceReattemptException > -- > > Key: GEODE-5273 > URL: https://issues.apache.org/jira/browse/GEODE-5273 > Project: Geode > Issue Type: Bug > Components: functions >Reporter: nabarun >Priority: Major > Fix For: 1.7.0 > > > In waitForCacheOrFunctionException ForceReattemptException is wrapped in > another ForceReattempException again. > This function should directly throw the exception rather than wrapping it > again -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5272) CacheClosedException should not be wrapped in a TypeMismatchException
[ https://issues.apache.org/jira/browse/GEODE-5272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] nabarun updated GEODE-5272: --- Fix Version/s: (was: 1.8.0) 1.7.0 > CacheClosedException should not be wrapped in a TypeMismatchException > - > > Key: GEODE-5272 > URL: https://issues.apache.org/jira/browse/GEODE-5272 > Project: Geode > Issue Type: Bug > Components: querying >Reporter: nabarun >Priority: Major > Labels: pull-request-available > Fix For: 1.7.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > In CompiledIteratorDef, if the cache gets closed in between evaluating the > query, the exception is wrapped in a TypeMismatchException > Fix: Throw the CacheClosedException as it is. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5274) Handle closing CacheClientProxy during cq execution
[ https://issues.apache.org/jira/browse/GEODE-5274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] nabarun updated GEODE-5274: --- Fix Version/s: (was: 1.8.0) 1.7.0 > Handle closing CacheClientProxy during cq execution > --- > > Key: GEODE-5274 > URL: https://issues.apache.org/jira/browse/GEODE-5274 > Project: Geode > Issue Type: Bug > Components: cq >Reporter: nabarun >Priority: Major > Labels: pull-request-available > Fix For: 1.7.0 > > Time Spent: 20m > Remaining Estimate: 0h > > During execution of a cq the CacheClientProxy may be closed resulting in > operations being executed on null values. > Null checks are needed at in executeCQ to make sure that the CacheClientProxy > is still active. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5276) transaction commits can cause CachePerfStats entries to go negative
[ https://issues.apache.org/jira/browse/GEODE-5276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] nabarun updated GEODE-5276: --- Fix Version/s: (was: 1.8.0) 1.7.0 > transaction commits can cause CachePerfStats entries to go negative > --- > > Key: GEODE-5276 > URL: https://issues.apache.org/jira/browse/GEODE-5276 > Project: Geode > Issue Type: Bug > Components: transactions >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: pull-request-available > Fix For: 1.7.0 > > Time Spent: 20m > Remaining Estimate: 0h > > The statistic CachePerfStats entries is a count of the number of entries in a > region or cache. But the transaction code in some cases decrements it too > many times causing it to go negative. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5277) Server affinity causes wrong transaction failover behavior
[
https://issues.apache.org/jira/browse/GEODE-5277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
nabarun updated GEODE-5277:
---
Fix Version/s: (was: 1.8.0)
1.7.0
> Server affinity causes wrong transaction failover behavior
> --
>
> Key: GEODE-5277
> URL: https://issues.apache.org/jira/browse/GEODE-5277
> Project: Geode
> Issue Type: Bug
> Components: transactions
>Reporter: Jianxia Chen
>Assignee: Jianxia Chen
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.7.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> A transaction is initiated from a client, and is successfully committed on
> the server. Client has received TXCommitMessage from the server. It has a
> listener callbacks need pdx Type from the server, so it sends a
> GetPDXEnumByIdOp message to the server. The connection to the server is lost,
> so it failed over to a new server. Because it is still using affinity server,
> so it sends TXFailoverOp trying to locate the transaction hosts. However,
> GetPDXEnumByIdOp message does not set transaction id as it does not
> participate in a transaction. This cause server failed with the assertion and
> send back the InternalGemFireError to the client.
> This could be solved by unset the serverAffinity ThreadLocal after client
> receives the TXCommitMessage but before callbacks are invoked.
>
> {code}
> at
> org.apache.geode.cache.client.internal.AbstractOp.processAck(AbstractOp.java:263)
> at
> org.apache.geode.cache.client.internal.TXFailoverOp$TXFailoverOpImpl.processResponse(TXFailoverOp.java:52)
> at
> org.apache.geode.cache.client.internal.AbstractOp.processResponse(AbstractOp.java:226)
> at
> org.apache.geode.cache.client.internal.AbstractOp.attemptReadResponse(AbstractOp.java:211)
> at
> org.apache.geode.cache.client.internal.AbstractOp.attempt(AbstractOp.java:387)
> at
> org.apache.geode.cache.client.internal.ConnectionImpl.execute(ConnectionImpl.java:276)
> at
> org.apache.geode.cache.client.internal.pooling.PooledConnection.execute(PooledConnection.java:327)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.executeWithPossibleReAuthentication(OpExecutorImpl.java:885)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.executeOnServer(OpExecutorImpl.java:378)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.executeWithServerAffinity(OpExecutorImpl.java:231)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:140)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:127)
> at
> org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:782) at
> org.apache.geode.cache.client.internal.TXFailoverOp.execute(TXFailoverOp.java:29)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.executeWithServerAffinity(OpExecutorImpl.java:265)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:140)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:127)
> at
> org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:782) at
> org.apache.geode.cache.client.internal.GetPDXEnumByIdOp.execute(GetPDXEnumByIdOp.java:34)
> at
> org.apache.geode.pdx.internal.ClientTypeRegistration.getEnumById(ClientTypeRegistration.java:198)
> at
> org.apache.geode.pdx.internal.TypeRegistry.getEnumInfoById(TypeRegistry.java:442)
> at
> org.apache.geode.pdx.internal.TypeRegistry.getEnumById(TypeRegistry.java:418)
> at
> org.apache.geode.internal.InternalDataSerializer.readPdxEnum(InternalDataSerializer.java:2323)
> at
> org.apache.geode.internal.InternalDataSerializer.basicReadObject(InternalDataSerializer.java:3075)
> at org.apache.geode.DataSerializer.readObject(DataSerializer.java:2978) at
> org.apache.geode.pdx.internal.PdxInputStream.readObject(PdxInputStream.java:251)
> at
> org.apache.geode.pdx.internal.PdxInputStream.readObject(PdxInputStream.java:96)
> at
> org.apache.geode.pdx.internal.PdxReaderImpl.readObject(PdxReaderImpl.java:333)
> at
> org.apache.geode.pdx.internal.PdxInstanceImpl.readObject(PdxInstanceImpl.java:527)
> at
> org.apache.geode.pdx.internal.PdxReaderImpl.readObject(PdxReaderImpl.java:326)
> at
> org.apache.geode.pdx.internal.PdxInstanceImpl.readObject(PdxInstanceImpl.java:522)
> at util.VersionedValueHolder.myFromData(VersionedValueHolder.java:242) at
> util.PdxVersionedValueHolder.fromData(PdxVersionedValueHolder.java:95) at
> org.apache.geode.pdx.internal.PdxReaderImpl.basicGetObject(PdxReaderImpl.java:737)
> at
> org.apache.geode.pdx.internal.PdxInstanceImpl.basicGetObject(PdxInstanceImpl.java:600)
> at
>
[jira] [Updated] (GEODE-5278) Unexpected CommitConflictException caused by faulty region synchronization
[
https://issues.apache.org/jira/browse/GEODE-5278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
nabarun updated GEODE-5278:
---
Fix Version/s: (was: 1.8.0)
1.7.0
> Unexpected CommitConflictException caused by faulty region synchronization
> --
>
> Key: GEODE-5278
> URL: https://issues.apache.org/jira/browse/GEODE-5278
> Project: Geode
> Issue Type: Bug
> Components: regions
>Reporter: Bruce Schuchardt
>Assignee: Bruce Schuchardt
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.7.0
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> I was running tests for another ticket and found that several times my test
> failed with a weird CommitConflictException. I traced this down to faulty
> region-synchronization code. When a server crashes other members exchange
> version vector information about the crashed server in order to recover
> operations that may have only reached a subset of the servers. This is
> supposed to return only region entries concerning the crashed server but I
> noticed it also returned all entries modified by the requesting server as
> well.
> {noformat}
> before the transaction begins we have v48 of key Object_194:
> bridgegemfire5_2643/system.log: [fine 2018/05/31 22:28:14.813 PDT
> bridgegemfire5_trout_2643 tid=0x83]
> generated tag {v48; rv220; ds=1; time=1527830894813}; key=Object_194;
> oldvalue=util.QueryObject with id 1775 (contains 1 levels,
> aPrimitiveLong=-197) newvalue=util.QueryObject with id 1780 (contains 1
> levels, aPrimitiveLong=197) client=edgegemfire1_trout_377 region=/testRegion;
> rvv=RegionVersionVector{rv220 gc0}@2057394665
> server "bridge5" begins a GII sync with "bridge4" for loss of server "bridge2"
> bridgegemfire5_2643/system.log: [fine 2018/05/31 22:28:15.144 PDT
> bridgegemfire5_trout_2643 tid=0x7d]
> Sending (InitialImageOperation$RequestImageMessage(region path='/testRegion';
> sender=trout(bridgegemfire5_trout_2643:2643):1028; keysOnly=false;
> processorId=712; waitForInit=false; checkTombstoneVersions=false;
> lostMember=trout(bridgegemfire2_trout_3364:3364):1025;
> versionVector=RegionVersionVector[trout(bridgegemfire5_trout_2643:2643):1028={rv-1
> gc0 localVersion=0 local exceptions=[]}
> others={trout(bridgegemfire2_trout_3364:3364):1025={rv-1 bsv1
> bs=[]}, gc={}]; unfinished keys=null)) to 1 peers
> ([trout(bridgegemfire4_trout_3956:3956):1029]) via tcp/ip
> the transaction begins
> bridgegemfire5_2643/system.log: [fine 2018/05/31 22:28:15.201 PDT
> bridgegemfire5_trout_2643 tid=0x83]
> Server connection from
> [identity(trout(edgegemfire1_trout_377:377:loner):44872:32e1cab9:edgegemfire1_trout_377,connection=1;
> port=46982]: Received 7.0 get request (31 bytes) from /10.118.26.122:46982
> timeout: 0 for region /testRegion key Object_194 txId 105
> bridge5 gets back an odd result - the sync GII should only have entries
> modified by "bridge2" but it has stuff from "bridge5", including Object_194
> with the same revision as bridge5 already contains
> bridgegemfire5_2643/system.log: [fine 2018/05/31 22:28:15.203 PDT
> bridgegemfire5_trout_2643
> tid=0x70] processed these initial image keys: [Object_179,v={v1; rv42;
> mbr=trout(bridgegemfire5_trout_2643):1028; ds=1; time=1527830690427;
> remote}, Object_185,v={v1; rv63;
> mbr=trout(bridgegemfire5_trout_2643):1028; ds=1; time=1527830691143;
> remote}, Object_190,v={v1; rv74;
> mbr=trout(bridgegemfire5_trout_2643):1028; ds=1; time=1527830691522;
> remote}, Object_228,v={v1; rv133;
> mbr=trout(bridgegemfire5_trout_2643):1028; ds=1; time=1527830760434;
> remote}, Object_257,v={v1; rv181;
> mbr=trout(bridgegemfire5_trout_2643):1028; ds=1; time=1527830829825;
> remote}, Object_269,v={v1; rv199;
> mbr=trout(bridgegemfire5_trout_2643):1028; ds=1; time=1527830830324;
> remote}, Object_151,v={v1; rv1;
> mbr=trout(bridgegemfire5_trout_2643):1028; ds=1; time=1527830689202;
> remote}, Object_212,v={v1; rv109;
> mbr=trout(bridgegemfire5_trout_2643):1028; ds=1; time=1527830759779;
> remote}, Object_204,v={v1; rv99;
> mbr=trout(bridgegemfire5_trout_2643):1028; ds=1; time=1527830759529;
> remote}, Object_163,v={v1; rv16;
> mbr=trout(bridgegemfire5_trout_2643):1028; ds=1; time=1527830689717;
> remote}, Object_256,v={v1; rv179;
> mbr=trout(bridgegemfire5_trout_2643):1028; ds=1; time=1527830829744;
> remote}, Object_251,v={v1; rv171;
> mbr=trout(bridgegemfire5_trout_2643):1028; ds=1; time=1527830829527;
> remote}, Object_193,v={v1; rv81;
> mbr=trout(bridgegemfire5_trout_2643):1028; ds=1; time=1527830758973;
> remote}, Object_220,v={v1; rv121;
> mbr=trout(bridgegemfire5_trout_2643):1028; ds=1; time=1527830760065;
> remote}, Object_215,v={v1; rv115;
>
[jira] [Updated] (GEODE-5292) Replace with concurrent clear and destroy leaks off heap memory
[ https://issues.apache.org/jira/browse/GEODE-5292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] nabarun updated GEODE-5292: --- Fix Version/s: (was: 1.8.0) 1.7.0 > Replace with concurrent clear and destroy leaks off heap memory > --- > > Key: GEODE-5292 > URL: https://issues.apache.org/jira/browse/GEODE-5292 > Project: Geode > Issue Type: Bug > Components: regions >Reporter: Dan Smith >Assignee: Dan Smith >Priority: Major > Labels: pull-request-available, swat > Fix For: 1.7.0 > > Time Spent: 1h 40m > Remaining Estimate: 0h > > For a region that has been configured with off-heap storage and overflow to > disk, memory can be leaked if > * region clear > * region destroy > * region replace > all happen concurrently. The root cause appears to be region clear modifying > entries for values stored on disk without synchronizing the entries. This > prevents replace from freeing the off-heap memory for the new value when the > replace fails because the region is being destroyed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5296) Revise introductory docs on transactions
[ https://issues.apache.org/jira/browse/GEODE-5296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] nabarun updated GEODE-5296: --- Fix Version/s: (was: 1.8.0) 1.7.0 > Revise introductory docs on transactions > > > Key: GEODE-5296 > URL: https://issues.apache.org/jira/browse/GEODE-5296 > Project: Geode > Issue Type: New Feature > Components: docs >Reporter: Karen Smoler Miller >Assignee: Karen Smoler Miller >Priority: Major > Labels: pull-request-available > Fix For: 1.7.0 > > Time Spent: 1h > Remaining Estimate: 0h > > Do a complete rewrite of the introductory prose on transactions. Help Geode > users to know how the ACID semantics are implemented in Geode. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5287) Simplify documentation of transactions
[ https://issues.apache.org/jira/browse/GEODE-5287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] nabarun updated GEODE-5287: --- Fix Version/s: (was: 1.8.0) 1.7.0 > Simplify documentation of transactions > -- > > Key: GEODE-5287 > URL: https://issues.apache.org/jira/browse/GEODE-5287 > Project: Geode > Issue Type: New Feature > Components: docs >Reporter: Karen Smoler Miller >Assignee: Karen Smoler Miller >Priority: Major > Labels: pull-request-available > Fix For: 1.7.0 > > Time Spent: 20m > Remaining Estimate: 0h > > The documentation is overly complicated when describing transactions within > Geode. As a first step towards simplification, extract the important > semantic info on Geode's capabilities with respect to ACID transactions from > its buried location and combine it with the About Transactions overview > information. Rename the section too. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5290) Use of ResultsCollectionPdxDeserializerWrapper iterator results in NPE
[
https://issues.apache.org/jira/browse/GEODE-5290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
nabarun updated GEODE-5290:
---
Fix Version/s: (was: 1.8.0)
1.7.0
> Use of ResultsCollectionPdxDeserializerWrapper iterator results in NPE
> --
>
> Key: GEODE-5290
> URL: https://issues.apache.org/jira/browse/GEODE-5290
> Project: Geode
> Issue Type: Bug
> Components: querying
>Reporter: Biju Kunjummen
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.7.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Use of default constructor of ResultsCollectionPdxDeserializerWrapper and
> getting an iterator from it results in NPE:
> {{SelectResults sr1 = new ResultsCollectionPdxDeserializerWrapper();}}
> {{sr1.asList();}}
>
> Results in :
>
> {{java.lang.NullPointerException}}
> {{at
> org.apache.geode.cache.query.internal.ResultsCollectionPdxDeserializerWrapper.iterator(ResultsCollectionPdxDeserializerWrapper.java:52)}}
> {{at
> org.apache.geode.cache.query.internal.ResultsCollectionPdxDeserializerWrapper.toArray(ResultsCollectionPdxDeserializerWrapper.java:174)}}
> {{at java.util.ArrayList.(ArrayList.java:178)}}
> {{at
> org.apache.geode.cache.query.internal.ResultsCollectionPdxDeserializerWrapper.asList(ResultsCollectionPdxDeserializerWrapper.java:208)}}
>
> Additionally, user reported exception with a code along these lines:
>
> {{When a query with `SUM` aggregate is called:}}
> {{select sum(totalHoldingsValue) from /ExternalAccounts where uniqueAcctId IN
> SET (‘4’,‘5’,‘6’,‘|')}}
> Per the ticket a code of this type:
> {{String query = “select sum(totalHoldingsValue) from
> /ExternalAccounts where uniqueAcctId IN SET (” + externalAccountNumbers +
> “)”;}}
> {{SelectResults preResults = executeTotalsQuery(queryService, query,
> externalAccountsRegion);}}
> {{logger.info(“query = ” + query.toString());}}
> {{logger.info(“query return object= ” + preResults.getClass().getName());}}
> {{logger.info(“query return size= ” + preResults.size());}}{{Iterator it =
> preResults.iterator();}}
> {{if (it.hasNext())}}{{{ logger.info(“query return = ” + it.next()); }}}
> {{List results = (List) preResults.asList();
> threw an exception :
> {{Index: 0, Size: 0}}
> {{java.util.ArrayList.rangeCheck(ArrayList.java:653)}}
> {{java.util.ArrayList.get(ArrayList.java:429)}}
> {{io.pivotal.bofa.builder.PortfolioTotalsBuilder.queryExternalPortfolioTotals(PortfolioTotalsBuilder.java:81)}}
> {{io.pivotal.bofa.builder.PortfolioTotalsBuilder.build(PortfolioTotalsBuilder.java:43)}}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5283) Client transaction fails with TransactionException: GemFireInternalException: RemoteOperationException: cache is closing
[
https://issues.apache.org/jira/browse/GEODE-5283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
nabarun updated GEODE-5283:
---
Fix Version/s: (was: 1.8.0)
1.7.0
> Client transaction fails with TransactionException: GemFireInternalException:
> RemoteOperationException: cache is closing
>
>
> Key: GEODE-5283
> URL: https://issues.apache.org/jira/browse/GEODE-5283
> Project: Geode
> Issue Type: Test
> Components: transactions
>Reporter: Bruce Schuchardt
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.7.0
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> In January 2018 RemoteOperationMessage was altered to return different
> exceptions, notably to not return a CacheClosedException to the sender.
> Instead it sends a RemoteOperationException with the text "cache is closing".
> This RemoteOperationException is then rethrown when the reply is received
> but there is no handler for this and a generic GemFireInternalException is
> thrown. That in turn is caught and wrapped in a TransactionException and
> returned to the client.
> Error handling needs to be altered so that this situation results in a
> TransactionDataNodeHasDepartedException.
> {noformat}
> unexpected exception org.apache.geode.cache.TransactionException:
> org.apache.geode.InternalGemFireException: unexpected exception on member
> rs-FullRegression210400555i32xlarge-hydra-client-27(bridgegemfire1_rs-FullRegression210400555i32xlarge-hydra-client-27_28567:28567):1032,
> caused by org.apache.geode.InternalGemFireException: unexpected exception on
> member
> rs-FullRegression210400555i32xlarge-hydra-client-27(bridgegemfire1_rs-FullRegression210400555i32xlarge-hydra-client-27_28567:28567):1032
> at
> org.apache.geode.internal.cache.tx.AbstractPeerTXRegionStub.getRegionKeysForIteration(AbstractPeerTXRegionStub.java:54)
> at
> org.apache.geode.internal.cache.TXStateStub.getRegionKeysForIteration(TXStateStub.java:678)
> at
> org.apache.geode.internal.cache.TXStateStub.getRegionKeysForIteration(TXStateStub.java:45)
> at
> org.apache.geode.internal.cache.TXStateProxyImpl.getRegionKeysForIteration(TXStateProxyImpl.java:772)
> at
> org.apache.geode.internal.cache.EntriesSet$EntriesIterator.createIterator(EntriesSet.java:213)
> at
> org.apache.geode.internal.cache.EntriesSet$EntriesIterator.(EntriesSet.java:117)
> at
> org.apache.geode.internal.cache.EntriesSet.iterator(EntriesSet.java:83)
> at
> org.apache.geode.internal.cache.tier.sockets.command.KeySet.fillAndSendKeySetResponseChunks(KeySet.java:171)
> at
> org.apache.geode.internal.cache.tier.sockets.command.KeySet.cmdExecute(KeySet.java:129)
> at
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:157)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMsg(ServerConnection.java:868)
> at
> org.apache.geode.internal.cache.tier.sockets.OriginalServerConnection.doOneMessage(OriginalServerConnection.java:85)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1248)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl$4$1.run(AcceptorImpl.java:644)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: org.apache.geode.InternalGemFireException: unexpected exception on
> member
> rs-FullRegression210400555i32xlarge-hydra-client-27(bridgegemfire1_rs-FullRegression210400555i32xlarge-hydra-client-27_28567:28567):1032
> at
> org.apache.geode.distributed.internal.ReplyException.handleCause(ReplyException.java:100)
> at
> org.apache.geode.internal.cache.tx.RemoteFetchKeysMessage$FetchKeysResponse.waitForKeys(RemoteFetchKeysMessage.java:433)
> at
> org.apache.geode.internal.cache.tx.AbstractPeerTXRegionStub.getRegionKeysForIteration(AbstractPeerTXRegionStub.java:45)
> ... 16 more
> Caused by: org.apache.geode.internal.cache.RemoteOperationException: cache is
> closing
> at
> org.apache.geode.internal.cache.tx.RemoteOperationMessage.process(RemoteOperationMessage.java:241)
> at
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:382)
> at
> org.apache.geode.distributed.internal.DistributionMessage.schedule(DistributionMessage.java:440)
> at
>
[jira] [Updated] (GEODE-5298) User Guide: Document Transactions + Functions Limitation
[
https://issues.apache.org/jira/browse/GEODE-5298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
nabarun updated GEODE-5298:
---
Fix Version/s: (was: 1.8.0)
1.7.0
> User Guide: Document Transactions + Functions Limitation
>
>
> Key: GEODE-5298
> URL: https://issues.apache.org/jira/browse/GEODE-5298
> Project: Geode
> Issue Type: Improvement
> Components: docs
>Reporter: Dave Barnes
>Assignee: Dave Barnes
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.7.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> By design, you can't execute a function within a transaction through the
> {{FunctionService.onServer}} API. This is not fully documented within the
> Transactions and Functions section of the user guide.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5300) Remove mention of a developer by name in a javadoc
[ https://issues.apache.org/jira/browse/GEODE-5300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] nabarun updated GEODE-5300: --- Fix Version/s: (was: 1.8.0) 1.7.0 > Remove mention of a developer by name in a javadoc > -- > > Key: GEODE-5300 > URL: https://issues.apache.org/jira/browse/GEODE-5300 > Project: Geode > Issue Type: Task > Components: membership >Reporter: Bruce Schuchardt >Assignee: Bruce Schuchardt >Priority: Major > Fix For: 1.7.0 > > > Remove mention of a developer by name in > ReplyProcessor21.allowReplyFromSender() -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5302) the totalLiveCount should be set to 0 after oplog is compacted (all live data has been copied forward to new oplog)
[ https://issues.apache.org/jira/browse/GEODE-5302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] nabarun updated GEODE-5302: --- Fix Version/s: (was: 1.8.0) 1.7.0 > the totalLiveCount should be set to 0 after oplog is compacted (all live data > has been copied forward to new oplog) > > > Key: GEODE-5302 > URL: https://issues.apache.org/jira/browse/GEODE-5302 > Project: Geode > Issue Type: Bug > Components: persistence >Affects Versions: 1.1.0, 1.2.0, 1.3.0, 1.4.0, 1.5.0, 1.6.0, 1.7.0 >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: pull-request-available > Fix For: 1.7.0 > > Time Spent: 20m > Remaining Estimate: 0h > > There are race conditions in which liveEntries list is empty but the > liveCount has not yet been decremented. liveCount should be set to 0 after > liveEntries list is successfully copied forward. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5310) InternalGemFireError while creating bucket
[
https://issues.apache.org/jira/browse/GEODE-5310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
nabarun updated GEODE-5310:
---
Fix Version/s: (was: 1.8.0)
1.7.0
> InternalGemFireError while creating bucket
> --
>
> Key: GEODE-5310
> URL: https://issues.apache.org/jira/browse/GEODE-5310
> Project: Geode
> Issue Type: Bug
> Components: regions
>Reporter: Barry Oglesby
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.7.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> {noformat}
> org.apache.geode.InternalGemFireError
> at Remote Member
> 'client-20(dataStoregemfire3_client-20_9820:9820):1027' in
> org.apache.geode.internal.Assert.throwError(Assert.java:96)
> at Remote Member
> 'client-20(dataStoregemfire3_client-20_9820:9820):1027' in
> org.apache.geode.internal.Assert.assertTrue(Assert.java:56)
> at Remote Member
> 'client-20(dataStoregemfire3_client-20_9820:9820):1027' in
> org.apache.geode.internal.cache.partitioned.RegionAdvisor.getPrimaryMemberForBucket(RegionAdvisor.java:1196)
> at Remote Member
> 'client-20(dataStoregemfire3_client-20_9820:9820):1027' in
> org.apache.geode.internal.cache.PartitionedRegion.getBucketPrimary(PartitionedRegion.java:8916)
> at Remote Member
> 'client-20(dataStoregemfire3_client-20_9820:9820):1027' in
> org.apache.geode.internal.cache.PartitionedRegion.waitForNoStorageOrPrimary(PartitionedRegion.java:3063)
> at Remote Member
> 'client-20(dataStoregemfire3_client-20_9820:9820):1027' in
> org.apache.geode.internal.cache.PartitionedRegion.getNodeForBucketWrite(PartitionedRegion.java:3048)
> at Remote Member
> 'client-20(dataStoregemfire3_client-20_9820:9820):1027' in
> org.apache.geode.internal.cache.PartitionedRegion.createBucket(PartitionedRegion.java:3235)
> at Remote Member
> 'client-20(dataStoregemfire3_client-20_9820:9820):1027' in
> org.apache.geode.internal.cache.PartitionedRegion.getDataRegionForWrite(PartitionedRegion.java:9410)
> at Remote Member
> 'client-20(dataStoregemfire3_client-20_9820:9820):1027' in
> org.apache.geode.internal.cache.TXState.txReadEntry(TXState.java:1435)
> at Remote Member
> 'client-20(dataStoregemfire3_client-20_9820:9820):1027' in
> org.apache.geode.internal.cache.TXState.txReadEntry(TXState.java:1425)
> at Remote Member
> 'client-20(dataStoregemfire3_client-20_9820:9820):1027' in
> org.apache.geode.internal.cache.TXState.getSerializedValue(TXState.java:1521)
> at Remote Member
> 'client-20(dataStoregemfire3_client-20_9820:9820):1027' in
> org.apache.geode.internal.cache.TXStateProxyImpl.getSerializedValue(TXStateProxyImpl.java:598)
> at Remote Member
> 'client-20(dataStoregemfire3_client-20_9820:9820):1027' in
> org.apache.geode.internal.cache.partitioned.GetMessage.operateOnPartitionedRegion(GetMessage.java:170)
> at Remote Member
> 'client-20(dataStoregemfire3_client-20_9820:9820):1027' in
> org.apache.geode.internal.cache.partitioned.PartitionMessage.process(PartitionMessage.java:340)
> at Remote Member
> 'client-20(dataStoregemfire3_client-20_9820:9820):1027' in
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:374)
> at Remote Member
> 'client-20(dataStoregemfire3_client-20_9820:9820):1027' in
> org.apache.geode.distributed.internal.DistributionMessage.schedule(DistributionMessage.java:432)
> at Remote Member
> 'client-20(dataStoregemfire3_client-20_9820:9820):1027' in
> org.apache.geode.distributed.internal.DistributionManager.scheduleIncomingMessage(DistributionManager.java:3554)
> at Remote Member
> 'client-20(dataStoregemfire3_client-20_9820:9820):1027' in
> org.apache.geode.distributed.internal.DistributionManager.handleIncomingDMsg(DistributionManager.java:3188)
> at Remote Member
> 'client-20(dataStoregemfire3_client-20_9820:9820):1027' in
> org.apache.geode.distributed.internal.DistributionManager$MyListener.messageReceived(DistributionManager.java:4363)
> at Remote Member
> 'client-20(dataStoregemfire3_client-20_9820:9820):1027' in
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.dispatchMessage(GMSMembershipManager.java:1127)
> at Remote Member
> 'client-20(dataStoregemfire3_client-20_9820:9820):1027' in
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.handleOrDeferMessage(GMSMembershipManager.java:1045)
> at Remote Member
> 'client-20(dataStoregemfire3_client-20_9820:9820):1027' in
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager$MyDCReceiver.messageReceived(GMSMembershipManager.java:408)
> at Remote Member
> 'client-20(dataStoregemfire3_client-20_9820:9820):1027' in
> org.apache.geode.distributed.internal.direct.DirectChannel.receive(DirectChannel.java:715)
> at Remote Member
>
[jira] [Updated] (GEODE-5306) add disconnect/reconnect of members to clusterStarterRule
[ https://issues.apache.org/jira/browse/GEODE-5306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] nabarun updated GEODE-5306: --- Fix Version/s: (was: 1.8.0) 1.7.0 > add disconnect/reconnect of members to clusterStarterRule > - > > Key: GEODE-5306 > URL: https://issues.apache.org/jira/browse/GEODE-5306 > Project: Geode > Issue Type: Improvement > Components: tests >Reporter: Helena Bales >Assignee: Jinmei Liao >Priority: Major > Labels: pull-request-available > Fix For: 1.7.0 > > Time Spent: 2h 40m > Remaining Estimate: 0h > > Currently there are lots of DUnit tests using different ways to perform a > disconnect/reconnect, and no one seems to know what the right way is. None of > the current methods of reconnecting seem to restore the system to a good > state. It would be nice to have an easy way to do this common task. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5307) Hang with servers all in waitForPrimaryMember and one server in NO_PRIMARY_HOSTING state
[ https://issues.apache.org/jira/browse/GEODE-5307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] nabarun updated GEODE-5307: --- Fix Version/s: (was: 1.8.0) 1.7.0 > Hang with servers all in waitForPrimaryMember and one server in > NO_PRIMARY_HOSTING state > > > Key: GEODE-5307 > URL: https://issues.apache.org/jira/browse/GEODE-5307 > Project: Geode > Issue Type: Bug > Components: regions >Affects Versions: 1.1.0, 1.2.0, 1.3.0, 1.2.1, 1.4.0, 1.5.0, 1.6.0 >Reporter: Bruce Schuchardt >Assignee: Bruce Schuchardt >Priority: Major > Labels: pull-request-available > Fix For: 1.7.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > I've run into a hang in a test where servers are continuously creating PRs, > doing putAll ops on them and closing/local-destroying the PR. Sometimes the > servers hang with any thread needing a particular bucket in > waitingForPrimaryMember(). > This seems to happen because of this sequence of events: > 1. two servers create a partitioned region > 2. one server initiates a putAll and requests the other server manage a bucket > 3. the putAll server closes or locally-destroys its region > 4. the close() operation completes > 5. the other server initializes its bucket and still uses the requesting > server as a primaryElector. This keeps it from deciding to volunteer to > become primary. > The problem is that the server that closed its region caused exceptions to be > thrown in the putAll thread and abandon creation of the bucket. No-one will > ever trip the switch that makes the other server become the primary for the > bucket. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5305) TXCommitMessage deserialization can result in warning if cache closes
[ https://issues.apache.org/jira/browse/GEODE-5305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] nabarun updated GEODE-5305: --- Fix Version/s: (was: 1.8.0) 1.7.0 > TXCommitMessage deserialization can result in warning if cache closes > - > > Key: GEODE-5305 > URL: https://issues.apache.org/jira/browse/GEODE-5305 > Project: Geode > Issue Type: Bug > Components: transactions >Affects Versions: 1.7.0 >Reporter: Jacob S. Barrett >Assignee: Jacob S. Barrett >Priority: Major > Labels: pull-request-available > Fix For: 1.7.0 > > Time Spent: 1.5h > Remaining Estimate: 0h > > TXCommitMessage deserialization can result in warning, did not read X bytes, > if cache closes while deserializing. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5312) A client transaction may be removed by FindRemoteTXMessage during transaction failover
[ https://issues.apache.org/jira/browse/GEODE-5312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] nabarun updated GEODE-5312: --- Fix Version/s: (was: 1.8.0) 1.7.0 > A client transaction may be removed by FindRemoteTXMessage during transaction > failover > -- > > Key: GEODE-5312 > URL: https://issues.apache.org/jira/browse/GEODE-5312 > Project: Geode > Issue Type: Bug > Components: transactions >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: pull-request-available > Fix For: 1.7.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > During client transaction, the connection can be lost. The client will > failover to another server. The new server will find if any server hosts the > transaction. If the original server have not received/processed the message > yet, the FindRemoteTXMessage will call removeTXHostedState to remove the tx. > It is possible fo the original server process the a in-flight message from > client at the same time. This will cause a transaction no longer in the > hostedTXStates map. If the transaction operates on a offheap region, this > will lead to offheap leak. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5311) User Guide - simplify navigation for "Client Transactions" section
[ https://issues.apache.org/jira/browse/GEODE-5311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] nabarun updated GEODE-5311: --- Fix Version/s: (was: 1.8.0) 1.7.0 > User Guide - simplify navigation for "Client Transactions" section > -- > > Key: GEODE-5311 > URL: https://issues.apache.org/jira/browse/GEODE-5311 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Major > Fix For: 1.7.0 > > > The "Client Transactions" section has short subsections which do not need > entries in the left-hand navigation pane. Remove the subnav links for those > subsections. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5317) NullPointerException in InternalDistributedSystem.reconnect while simultaneously disconnecting
[
https://issues.apache.org/jira/browse/GEODE-5317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
nabarun updated GEODE-5317:
---
Fix Version/s: (was: 1.8.0)
1.7.0
> NullPointerException in InternalDistributedSystem.reconnect while
> simultaneously disconnecting
> --
>
> Key: GEODE-5317
> URL: https://issues.apache.org/jira/browse/GEODE-5317
> Project: Geode
> Issue Type: Bug
> Components: membership
>Reporter: Barry Oglesby
>Priority: Major
> Fix For: 1.7.0
>
>
> The test is shutting down the distribute system:
> {noformat}
> [info 2016/11/12 12:45:01.170 UTC extraBridgegemfire5_client-06_22632
> tid=0xca] Shutting down
> DistributionManager
> client-06(extraBridgegemfire5_client-06_22632:22632):1039.
> {noformat}
> At the same time, the system is being forcibly disconnected:
> {noformat}
> [severe 2016/11/12 12:45:01.324 UTC extraBridgegemfire5_client-06_22632
> tid=0x23] Membership service failure: this
> member is no longer in the view but is initiating connections
> org.apache.geode.ForcedDisconnectException: this member is no longer in the
> view but is initiating connections
> at
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.forceDisconnect(GMSMembershipManager.java:2520)
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.forceDisconnect(GMSJoinLeave.java:999)
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.processRemoveRequest(GMSJoinLeave.java:635)
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.processMessage(GMSJoinLeave.java:1698)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1286)
> at org.jgroups.JChannel.invokeCallback(JChannel.java:816)
> at org.jgroups.JChannel.up(JChannel.java:741)
> at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1030)
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:165)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:390)
> at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1070)
> at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:785)
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:426)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.StatRecorder.up(StatRecorder.java:74)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.AddressManager.up(AddressManager.java:72)
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1601)
> at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1817)
> at org.jgroups.util.DirectExecutor.execute(DirectExecutor.java:10)
> at org.jgroups.protocols.TP.handleSingleMessage(TP.java:1729)
> at org.jgroups.protocols.TP.receive(TP.java:1654)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.Transport.receive(Transport.java:160)
> at org.jgroups.protocols.UDP$PacketReceiver.run(UDP.java:701)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> The ReconnectThread hits a NPE during reconnect.
> {noformat}
> [warning 2016/11/12 12:45:01.758 UTC extraBridgegemfire5_client-06_22632
> tid=0xe0] Exception caught while shutting down
> java.lang.NullPointerException
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.reconnect(InternalDistributedSystem.java:2788)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.tryReconnect(InternalDistributedSystem.java:2521)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect(InternalDistributedSystem.java:989)
> at
> org.apache.geode.distributed.internal.DistributionManager$MyListener.membershipFailure(DistributionManager.java:4299)
> at
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.uncleanShutdown(GMSMembershipManager.java:1530)
> at
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.lambda$forceDisconnect$18(GMSMembershipManager.java:2550)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> InternalDistributedSystem.java:2788 is:
> {code}
> reconnectDS.disconnect();
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5320) add a test for thread-owned connection cleanup
[ https://issues.apache.org/jira/browse/GEODE-5320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] nabarun updated GEODE-5320: --- Fix Version/s: (was: 1.8.0) 1.7.0 > add a test for thread-owned connection cleanup > -- > > Key: GEODE-5320 > URL: https://issues.apache.org/jira/browse/GEODE-5320 > Project: Geode > Issue Type: Test > Components: messaging >Reporter: Bruce Schuchardt >Assignee: Bruce Schuchardt >Priority: Major > Fix For: 1.7.0 > > > I noticed that while we have this nifty feature and perform cleanup in our > executor thread pools we actually have no tests to ensure that connection > cleanup works. Let's add one! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5319) LocatorSSLJUnitTest is an integration test
[ https://issues.apache.org/jira/browse/GEODE-5319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] nabarun updated GEODE-5319: --- Fix Version/s: (was: 1.8.0) 1.7.0 > LocatorSSLJUnitTest is an integration test > -- > > Key: GEODE-5319 > URL: https://issues.apache.org/jira/browse/GEODE-5319 > Project: Geode > Issue Type: Bug > Components: tests >Affects Versions: 1.7.0 >Reporter: Jacob S. Barrett >Priority: Major > Labels: pull-request-available > Fix For: 1.7.0 > > Time Spent: 20m > Remaining Estimate: 0h > > LocatorSSLJUnitTest is an integration test pretending to be a unit test. The > test modifies global state that can cause other tests running after it to > fail. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5323) ConfigurationProperties says the default socket-lease-time is 15000ms but it is 60000ms
[
https://issues.apache.org/jira/browse/GEODE-5323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
nabarun updated GEODE-5323:
---
Fix Version/s: (was: 1.8.0)
1.7.0
> ConfigurationProperties says the default socket-lease-time is 15000ms but it
> is 6ms
> ---
>
> Key: GEODE-5323
> URL: https://issues.apache.org/jira/browse/GEODE-5323
> Project: Geode
> Issue Type: Test
> Components: messaging
>Reporter: Bruce Schuchardt
>Assignee: Bruce Schuchardt
>Priority: Major
> Fix For: 1.7.0
>
>
> The default socket lease time is defined in DistributionConfig:
> {code}
> /**
>* The default value of the {@link
> ConfigurationProperties#SOCKET_LEASE_TIME} property
>*/
> int DEFAULT_SOCKET_LEASE_TIME = 6;
> {code}
> but it is documented to be 15 seconds
> {code}
> /**
>* The static String definition of the "socket-lease-time" property
> * name="socket-lease-time"/a>
>*
>* Description: The number of milliseconds a thread can keep
> exclusive access to a socket
>* that it is not actively using. Once a thread loses its lease to a socket
> it will need to
>* re-acquire a socket the next time it sends a message. A value of zero
> causes socket leases to
>* never expire. This property is ignored if "conserve-sockets" is true.
> Default: "15000"
>*
>* Allowed values: 0..60
>*
>* Since: GemFire 4.1
>*/
> String SOCKET_LEASE_TIME = "socket-lease-time";
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5330) Make sure temp files from GfshCommandRule are cleaned up after tests
[ https://issues.apache.org/jira/browse/GEODE-5330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] nabarun updated GEODE-5330: --- Fix Version/s: (was: 1.8.0) 1.7.0 > Make sure temp files from GfshCommandRule are cleaned up after tests > > > Key: GEODE-5330 > URL: https://issues.apache.org/jira/browse/GEODE-5330 > Project: Geode > Issue Type: Task >Reporter: Helena Bales >Priority: Major > Labels: pull-request-available > Fix For: 1.7.0 > > Time Spent: 20m > Remaining Estimate: 0h > > The GfshCommandRule creates temporary folders for use during the tests in > /var/folders/. > The current implementation of this leaves half of the created folders lying > around after the test has completed. > The GfshCommandRule should not leave any temporary folders after tests have > completed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5596) Client ends up with destroyed entry after invalidate()
[ https://issues.apache.org/jira/browse/GEODE-5596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16594077#comment-16594077 ] ASF subversion and git services commented on GEODE-5596: Commit a1135349e6cd1f934399346481ff62de806f33b3 in geode's branch refs/heads/feature/GEODE-5596 from [~bschuchardt] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=a113534 ] GEODE-5596 Client ends up with destroyed entry after invalidate() Undoing a couple of unnecessary test changes. > Client ends up with destroyed entry after invalidate() > -- > > Key: GEODE-5596 > URL: https://issues.apache.org/jira/browse/GEODE-5596 > Project: Geode > Issue Type: Improvement > Components: regions >Reporter: Bruce Schuchardt >Assignee: Bruce Schuchardt >Priority: Major > Labels: pull-request-available > Time Spent: 0.5h > Remaining Estimate: 0h > > If a client is doing a destroy, putAll and invalidate in separate threads and > the events align like this in the server: destroy then create then > invalidate, the client may end up having a destroyed entry instead of an > invalid entry. > This is a long standing issue with Geode (and formerly with GemFire) that a > client does not create an Invalid entry in some situations. A lot of this > was cleared up when we implemented concurrency controls in the cache but this > one corner case remains. > Fixing this issue requires a small change in behavior for client caches in > how they handle the invalidate() operation, but I think it's a change for the > better. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
