[jira] [Updated] (GEODE-8613) Remove exclusive access to pool connection creation/removal in native client
[ https://issues.apache.org/jira/browse/GEODE-8613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-8613: -- Labels: pull-request-available (was: ) > Remove exclusive access to pool connection creation/removal in native client > > > Key: GEODE-8613 > URL: https://issues.apache.org/jira/browse/GEODE-8613 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: pull-request-available > > The Apache Geode C++ native client uses a mutex to grant exclusive access to > the code that creates or removes pool connections (mutex_ member in > ThinClientPoolDM class). The reason behind seems to be to perform atomically > the creation of the connection and the update of the number of connections > (m_poolSize) of the pool so that the number of connections in the pool and > the counter are always aligned. > This mutex is also used to protect the concurrent access to the connection > queue structure (ConnectionQueue class). > So, the mutex is used for two different purposes. > Getting this mutex while creating/removing a pool connection has an impact in > the performance of the client because connections cannot be created > concurrently but there are also negative side effects that could lead to a > freeze of the client if the connection creation is taking a long time (for > example when the DNS is not available and name resolution calls take seconds > to be answered). > A particularly problematic case is that when a minimum number of connections > has been configured in the client, loadconditioning or connection expiration > is configured and the DNS becomes unavailable. If at a given point in time > the number of connections in the pool is lower than the minimum configured, > the thread that restores the minimum number of connections will try to create > a new connection and will not release the mutex until it has finished. This > will block other threads trying to get a connection from the queue > unnecessarily. > In this ticket, it is proposed to remove the locking of the mutex when the > connection is created or removed. An alternative could be to create a new > mutex for the creation or removal of connections so that the access to the > ConnectionQueue is not affected by the creation/removal of connections but I > do not consider it necessary just to maintain consistent (and not only > eventually consistent) the number of connection of the pool and the counter > of the connections (m_poolSize). > Note that this ticket does not propose to remove the use of the mutex to > access the ConnectionQueue. This will still be necessary to protect > concurrent access to the connection queue data structure. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8613) Remove exclusive access to pool connection creation/removal in native client
[ https://issues.apache.org/jira/browse/GEODE-8613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17215198#comment-17215198 ] ASF GitHub Bot commented on GEODE-8613: --- albertogpz commented on pull request #676: URL: https://github.com/apache/geode-native/pull/676#issuecomment-709806312 > I need more time to review this for correctness. I think the locking is required here to both protect concurrent updates to the `m_poolSize` value in various places as well as synchronize the CPU caches of this member. Wouldn't that already be guaranteed given that the type of `m_poolSize` is `std::atomic`? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Remove exclusive access to pool connection creation/removal in native client > > > Key: GEODE-8613 > URL: https://issues.apache.org/jira/browse/GEODE-8613 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > > The Apache Geode C++ native client uses a mutex to grant exclusive access to > the code that creates or removes pool connections (mutex_ member in > ThinClientPoolDM class). The reason behind seems to be to perform atomically > the creation of the connection and the update of the number of connections > (m_poolSize) of the pool so that the number of connections in the pool and > the counter are always aligned. > This mutex is also used to protect the concurrent access to the connection > queue structure (ConnectionQueue class). > So, the mutex is used for two different purposes. > Getting this mutex while creating/removing a pool connection has an impact in > the performance of the client because connections cannot be created > concurrently but there are also negative side effects that could lead to a > freeze of the client if the connection creation is taking a long time (for > example when the DNS is not available and name resolution calls take seconds > to be answered). > A particularly problematic case is that when a minimum number of connections > has been configured in the client, loadconditioning or connection expiration > is configured and the DNS becomes unavailable. If at a given point in time > the number of connections in the pool is lower than the minimum configured, > the thread that restores the minimum number of connections will try to create > a new connection and will not release the mutex until it has finished. This > will block other threads trying to get a connection from the queue > unnecessarily. > In this ticket, it is proposed to remove the locking of the mutex when the > connection is created or removed. An alternative could be to create a new > mutex for the creation or removal of connections so that the access to the > ConnectionQueue is not affected by the creation/removal of connections but I > do not consider it necessary just to maintain consistent (and not only > eventually consistent) the number of connection of the pool and the counter > of the connections (m_poolSize). > Note that this ticket does not propose to remove the use of the mutex to > access the ConnectionQueue. This will still be necessary to protect > concurrent access to the connection queue data structure. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8620) Actual redundancy of -1 in restore redundancy result
Aaron Lindsey created GEODE-8620: Summary: Actual redundancy of -1 in restore redundancy result Key: GEODE-8620 URL: https://issues.apache.org/jira/browse/GEODE-8620 Project: Geode Issue Type: Bug Components: gfsh, management Affects Versions: 1.13.0 Reporter: Aaron Lindsey Steps to reproduce: # Create a geode cluster with 1 locator and 2 servers. # Create a region of type PARTITION_REDUNDANT. # Put an entry into the region. # Trigger a restore redundancy operation via the management REST API or gfsh. # The result from the restore redundancy operation states that the actual redundancy for the region is -1. However, the expected redundancy at this point is 1 because there should be enough cache servers in the cluster to hold the redundant copy. # Stop one of the servers. # Trigger another restore redundancy operation via the management REST API or gfsh. # The result from the second restore redundancy operation again states that the actual redundancy for the region is -1. However, the region should be counted as having zero redundant copies at this point because there is only one cache server. I encountered this issue while using the management REST API, although the same issue happens in the gfsh command. I assume fixing the gfsh command would also fix the management REST API. If not, I can break this out into two separate JIRAs. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7703) Lucene IndexWriter Creation Failure
[
https://issues.apache.org/jira/browse/GEODE-7703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17215083#comment-17215083
]
Donal Evans commented on GEODE-7703:
After addressing https://issues.apache.org/jira/browse/GEODE-8536, this issue
may reoccur in cases where the IOException from creating the IndexWriter is
encountered consistently for more than 200 retries.
> Lucene IndexWriter Creation Failure
>
>
> Key: GEODE-7703
> URL: https://issues.apache.org/jira/browse/GEODE-7703
> Project: Geode
> Issue Type: Bug
> Components: lucene
>Reporter: Juan Ramos
>Assignee: Ernest Burghardt
>Priority: Major
> Labels: GeodeCommons
> Fix For: 1.12.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> While computing the index repository, the initialization might fail if there
> are modifications happening to the {{fileAndChunk}} region while the
> {{IndexWriter}} is being initialized.
> The exception stack trace varies from run to run but it always involves a
> {{IOException}} with different causes while reading the index file, some
> examples are shown below:
> {noformat}
> Caused by: java.io.FileNotFoundException: segments_1
> at
> org.apache.geode.cache.lucene.internal.filesystem.FileSystem.getFile(FileSystem.java:101)
> at
> org.apache.geode.cache.lucene.internal.directory.RegionDirectory.openInput(RegionDirectory.java:115)
> at
> org.apache.lucene.store.Directory.openChecksumInput(Directory.java:137)
> at
> org.apache.lucene.index.SegmentInfos.readCommit(SegmentInfos.java:286)
> at
> org.apache.lucene.index.IndexFileDeleter.(IndexFileDeleter.java:165)
> at org.apache.lucene.index.IndexWriter.(IndexWriter.java:974)
> at
> org.apache.geode.cache.lucene.internal.IndexRepositoryFactory.finishComputingRepository(IndexRepositoryFactory.java:130)
> at
> org.apache.geode.cache.lucene.internal.IndexRepositoryFactory.computeIndexRepository(IndexRepositoryFactory.java:67)
> at
> org.apache.geode.cache.lucene.internal.IndexRepositoryFactoryDistributedTest.lambda$testBecomePrimaryWhileIndexing$566b4a0f$5(IndexRepositoryFactoryDistributedTest.java:224)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.geode.test.dunit.internal.MethodInvoker.executeObject(MethodInvoker.java:123)
> at
> org.apache.geode.test.dunit.internal.RemoteDUnitVM.executeMethodOnObject(RemoteDUnitVM.java:78)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:357)
> at sun.rmi.transport.Transport$1.run(Transport.java:200)
> at sun.rmi.transport.Transport$1.run(Transport.java:197)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
> at
> sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:573)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:834)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:688)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:687)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> {noformat}
> Caused by: java.io.EOFException: Read past end of file _3z.si
> at
> org.apache.geode.cache.lucene.internal.directory.FileIndexInput.readByte(FileIndexInput.java:103)
> at
> org.apache.lucene.store.BufferedChecksumIndexInput.readByte(BufferedChecksumIndexInput.java:41)
> at org.apache.lucene.store.DataInput.readInt(DataInput.java:101)
> at org.apache.lucene.codecs.CodecUtil.checkHeader(CodecUtil.java:194)
> at
> org.apache.lucene.codecs.CodecUtil.checkIndexHeader(CodecUtil.java:255)
> at
> org.apache.lucene.codecs.lucene62.Lucene62SegmentInfoFormat.read(Lucene62SegmentInfoFormat.java:93)
> at
>
[jira] [Commented] (GEODE-8584) Message transmission fails with IllegalStateException in socket i/o code
[
https://issues.apache.org/jira/browse/GEODE-8584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17215076#comment-17215076
]
ASF GitHub Bot commented on GEODE-8584:
---
Bill opened a new pull request #5632:
URL: https://github.com/apache/geode/pull/5632
Thank you for submitting a contribution to Apache Geode.
In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:
### For all changes:
- [ ] Is there a JIRA ticket associated with this PR? Is it referenced in
the commit message?
- [ ] Has your PR been rebased against the latest commit within the target
branch (typically `develop`)?
- [ ] Is your initial contribution a single, squashed commit?
- [ ] Does `gradlew build` run cleanly?
- [ ] Have you written or updated unit tests to verify your changes?
- [ ] If adding new dependencies to the code, are these dependencies
licensed in a way that is compatible for inclusion under [ASF
2.0](http://www.apache.org/legal/resolved.html#category-a)?
### Note:
Please ensure that once the PR is submitted, check Concourse for build
issues and
submit an update to your PR as soon as possible. If you need help, please
send an
email to d...@geode.apache.org.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Message transmission fails with IllegalStateException in socket i/o code
>
>
> Key: GEODE-8584
> URL: https://issues.apache.org/jira/browse/GEODE-8584
> Project: Geode
> Issue Type: Bug
> Components: membership, messaging
>Affects Versions: 1.12.0, 1.13.0, 1.14.0
>Reporter: Bruce J Schuchardt
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.12.1, 1.14.0, 1.13.1
>
>
> Transmission of an update operation failed with a toData exception caused by
> an IllegalStateException in socket i/o code. It shouldn't be possible for
> this exception to happen unless multiple threads are using the buffer at the
> same time.
>
> {noformat}
> org.apache.geode.ToDataException: toData failed on dsfid=71 msg:null
> at
> org.apache.geode.internal.InternalDataSerializer.writeDSFID(InternalDataSerializer.java:1509)
> at
> org.apache.geode.internal.tcp.MsgStreamer.writeMessage(MsgStreamer.java:249)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:306)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:182)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:511)
> at
> org.apache.geode.distributed.internal.DistributionImpl.directChannelSend(DistributionImpl.java:346)
> at
> org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:291)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2053)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:1981)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendMessage(ClusterDistributionManager.java:2018)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.putOutgoing(ClusterDistributionManager.java:1083)
> at
> org.apache.geode.internal.cache.DistributedCacheOperation._distribute(DistributedCacheOperation.java:572)
> at
> org.apache.geode.internal.cache.DistributedCacheOperation.startOperation(DistributedCacheOperation.java:277)
> at
> org.apache.geode.internal.cache.DistributedCacheOperation.distribute(DistributedCacheOperation.java:318)
> at
> org.apache.geode.internal.cache.DistributedRegion.distributeUpdate(DistributedRegion.java:520)
> at
> org.apache.geode.internal.cache.DistributedRegion.basicPutPart3(DistributedRegion.java:498)
> at
> org.apache.geode.internal.cache.map.RegionMapPut.doAfterCompletionActions(RegionMapPut.java:307)
> at
> org.apache.geode.internal.cache.map.AbstractRegionMapPut.doPut(AbstractRegionMapPut.java:185)
> at
> org.apache.geode.internal.cache.map.AbstractRegionMapPut.runWhileLockedForCacheModification(AbstractRegionMapPut.java:119)
> at
> org.apache.geode.internal.cache.map.RegionMapPut.runWhileLockedForCacheModification(RegionMapPut.java:161)
> at
>
[jira] [Commented] (GEODE-8573) SerialGatewaySenderOperationsDistributedTest.testRestartSerialGatewaySendersWhilePutting
[
https://issues.apache.org/jira/browse/GEODE-8573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17215075#comment-17215075
]
Raymond Ingles commented on GEODE-8573:
---
These sure seem to be the same issue.
> SerialGatewaySenderOperationsDistributedTest.testRestartSerialGatewaySendersWhilePutting
>
>
> Key: GEODE-8573
> URL: https://issues.apache.org/jira/browse/GEODE-8573
> Project: Geode
> Issue Type: Bug
> Components: wan
>Affects Versions: 1.14.0
>Reporter: Mark Hanson
>Assignee: Mark Hanson
>Priority: Major
>
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/521]
>
> {noformat}
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderOperationsDistributedTest
> > testRestartSerialGatewaySendersWhilePutting[1: numDispatchers=3] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderOperationsDistributedTest$$Lambda$356/426344166.run
> in VM 5 running on Host 538fd3213f62 with 8 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:620)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:447)
> at
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderOperationsDistributedTest.testRestartSerialGatewaySendersWhilePutting(SerialGatewaySenderOperationsDistributedTest.java:407)
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderOperationsDistributedTest
> that uses org.apache.geode.internal.cache.wan.InternalGatewaySender,
> org.apache.geode.internal.cache.wan.InternalGatewaySenderint [Sender
> statistics unprocessed event map size] expected:<[0]> but was:<[3]> within 5
> minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:165)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:895)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:679)
> at
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderOperationsDistributedTest.validateSecondaryQueueSizeStat(SerialGatewaySenderOperationsDistributedTest.java:1216)
> at
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderOperationsDistributedTest.lambda$testRestartSerialGatewaySendersWhilePutting$bb17a952$23(SerialGatewaySenderOperationsDistributedTest.java:407)
> Caused by:
> org.junit.ComparisonFailure: [Sender statistics unprocessed event
> map size] expected:<[0]> but was:<[3]>
> at
> sun.reflect.GeneratedConstructorAccessor81.newInstance(Unknown Source)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderOperationsDistributedTest.lambda$validateSecondaryQueueSizeStat$8(SerialGatewaySenderOperationsDistributedTest.java:1219)
> {noformat}
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>
> [http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0389/test-results/distributedTest/1601774166/]
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> [http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0389/test-artifacts/1601774166/distributedtestfiles-OpenJDK8-1.14.0-build.0389.tgz]
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8573) SerialGatewaySenderOperationsDistributedTest.testRestartSerialGatewaySendersWhilePutting
[
https://issues.apache.org/jira/browse/GEODE-8573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17215071#comment-17215071
]
Geode Integration commented on GEODE-8573:
--
Seen in [DistributedTestOpenJDK8
#550|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/550]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0416/test-results/distributedTest/1602797185/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0416/test-artifacts/1602797185/distributedtestfiles-OpenJDK8-1.14.0-build.0416.tgz].
> SerialGatewaySenderOperationsDistributedTest.testRestartSerialGatewaySendersWhilePutting
>
>
> Key: GEODE-8573
> URL: https://issues.apache.org/jira/browse/GEODE-8573
> Project: Geode
> Issue Type: Bug
> Components: wan
>Affects Versions: 1.14.0
>Reporter: Mark Hanson
>Assignee: Mark Hanson
>Priority: Major
>
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/521]
>
> {noformat}
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderOperationsDistributedTest
> > testRestartSerialGatewaySendersWhilePutting[1: numDispatchers=3] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderOperationsDistributedTest$$Lambda$356/426344166.run
> in VM 5 running on Host 538fd3213f62 with 8 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:620)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:447)
> at
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderOperationsDistributedTest.testRestartSerialGatewaySendersWhilePutting(SerialGatewaySenderOperationsDistributedTest.java:407)
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderOperationsDistributedTest
> that uses org.apache.geode.internal.cache.wan.InternalGatewaySender,
> org.apache.geode.internal.cache.wan.InternalGatewaySenderint [Sender
> statistics unprocessed event map size] expected:<[0]> but was:<[3]> within 5
> minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:165)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:895)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:679)
> at
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderOperationsDistributedTest.validateSecondaryQueueSizeStat(SerialGatewaySenderOperationsDistributedTest.java:1216)
> at
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderOperationsDistributedTest.lambda$testRestartSerialGatewaySendersWhilePutting$bb17a952$23(SerialGatewaySenderOperationsDistributedTest.java:407)
> Caused by:
> org.junit.ComparisonFailure: [Sender statistics unprocessed event
> map size] expected:<[0]> but was:<[3]>
> at
> sun.reflect.GeneratedConstructorAccessor81.newInstance(Unknown Source)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderOperationsDistributedTest.lambda$validateSecondaryQueueSizeStat$8(SerialGatewaySenderOperationsDistributedTest.java:1219)
> {noformat}
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>
> [http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0389/test-results/distributedTest/1601774166/]
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> [http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0389/test-artifacts/1601774166/distributedtestfiles-OpenJDK8-1.14.0-build.0389.tgz]
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-8619) Create ServiceRegistry
Patrick Johnsn created GEODE-8619: - Summary: Create ServiceRegistry Key: GEODE-8619 URL: https://issues.apache.org/jira/browse/GEODE-8619 Project: Geode Issue Type: Improvement Reporter: Patrick Johnsn Create ServiceRegistry to hold single instances of services to be accessed statically where they are required. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8585) Redis SCAN, HSCAN, and SSCAN do not detect illegal parameters
[
https://issues.apache.org/jira/browse/GEODE-8585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17215020#comment-17215020
]
ASF GitHub Bot commented on GEODE-8585:
---
sabbey37 commented on a change in pull request #5627:
URL: https://github.com/apache/geode/pull/5627#discussion_r505871824
##
File path:
geode-redis/src/main/java/org/apache/geode/redis/internal/executor/key/ScanExecutor.java
##
@@ -36,91 +39,87 @@
public RedisResponse executeCommand(Command command, ExecutionHandlerContext
context) {
List commandElems = command.getProcessedCommand();
-if (commandElems.size() < 2) {
- return RedisResponse.error(ArityDef.SCAN);
-}
-
String cursorString = command.getStringKey();
-int cursor = 0;
-Pattern matchPattern = null;
-String globMatchString = null;
+BigInteger cursor;
+Pattern matchPattern;
+String globPattern = null;
int count = DEFAULT_COUNT;
+
try {
- cursor = Integer.parseInt(cursorString);
+ cursor = new BigInteger(cursorString).abs();
} catch (NumberFormatException e) {
return RedisResponse.error(ERROR_CURSOR);
}
-if (cursor < 0) {
+
+if (cursor.compareTo(UNSIGNED_LONG_CAPACITY) > 0) {
return RedisResponse.error(ERROR_CURSOR);
}
-if (commandElems.size() > 3) {
- try {
-byte[] bytes = commandElems.get(2);
-String tmp = Coder.bytesToString(bytes);
-if (tmp.equalsIgnoreCase("MATCH")) {
- bytes = commandElems.get(3);
- globMatchString = Coder.bytesToString(bytes);
-} else if (tmp.equalsIgnoreCase("COUNT")) {
- bytes = commandElems.get(3);
- count = Coder.bytesToInt(bytes);
-}
- } catch (NumberFormatException e) {
-return RedisResponse.error(ERROR_COUNT);
- }
+if (!cursor.equals(context.getScanCursor())) {
+ cursor = new BigInteger("0");
}
-if (commandElems.size() > 5) {
- try {
-byte[] bytes = commandElems.get(4);
-String tmp = Coder.bytesToString(bytes);
-if (tmp.equalsIgnoreCase("COUNT")) {
- bytes = commandElems.get(5);
- count = Coder.bytesToInt(bytes);
+for (int i = 2; i < commandElems.size(); i = i + 2) {
+ byte[] commandElemBytes = commandElems.get(i);
+ String keyword = Coder.bytesToString(commandElemBytes);
+ if (keyword.equalsIgnoreCase("MATCH")) {
+commandElemBytes = commandElems.get(i + 1);
+globPattern = Coder.bytesToString(commandElemBytes);
+
+ } else if (keyword.equalsIgnoreCase("COUNT")) {
+commandElemBytes = commandElems.get(i + 1);
+try {
+ count = Coder.bytesToInt(commandElemBytes);
+} catch (NumberFormatException e) {
+ return RedisResponse.error(ERROR_NOT_INTEGER);
+}
+
+if (count < 1) {
+ return RedisResponse.error(ERROR_SYNTAX);
}
- } catch (NumberFormatException e) {
-return RedisResponse.error(ERROR_COUNT);
- }
-}
-if (count < 0) {
- return RedisResponse.error(ERROR_COUNT);
+ } else {
+return RedisResponse.error(ERROR_SYNTAX);
+ }
}
try {
- matchPattern = convertGlobToRegex(globMatchString);
+ matchPattern = convertGlobToRegex(globPattern);
} catch (PatternSyntaxException e) {
- return RedisResponse.error(ERROR_ILLEGAL_GLOB);
+ LogService.getLogger().warn(
+ "Could not compile the pattern: '{}' due to the following exception:
'{}'. SCAN will return an empty list.",
+ globPattern, e.getMessage());
+ return RedisResponse.emptyScan();
}
-List returnList = getIteration(getDataRegion(context).keySet(),
matchPattern, count,
+List returnList = scan(getDataRegion(context).keySet(),
matchPattern, count,
cursor);
+context.setScanCursor(new BigInteger((String) returnList.get(0)));
return RedisResponse.scan(returnList);
}
- private List getIteration(Collection list, Pattern
matchPattern,
- int count, int cursor) {
-List returnList = new ArrayList<>();
+ private List scan(Collection list, Pattern
matchPattern,
Review comment:
Good idea! I just changed implemented it. Let me know what you think.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Redis SCAN, HSCAN, and SSCAN do not detect illegal parameters
> -
>
> Key: GEODE-8585
> URL: https://issues.apache.org/jira/browse/GEODE-8585
> Project: Geode
> Issue Type: Bug
> Components: redis
>
[jira] [Updated] (GEODE-8618) OQL grammar specification in docs is incomplete
[
https://issues.apache.org/jira/browse/GEODE-8618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-8618:
-
Component/s: docs
> OQL grammar specification in docs is incomplete
> ---
>
> Key: GEODE-8618
> URL: https://issues.apache.org/jira/browse/GEODE-8618
> Project: Geode
> Issue Type: Improvement
> Components: docs, querying
>Affects Versions: 1.11.0, 1.12.0, 1.13.0
>Reporter: John Blum
>Priority: Minor
>
> For example, there are no rules for the {{ORDER BY}} and {{LIMIT}} clauses.
> Referring to this section in the docs:
> https://geode.apache.org/docs/guide/113/developing/querying_basics/query_grammar_and_reserved_words.html
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8618) OQL grammar specification in docs is incomplete
[
https://issues.apache.org/jira/browse/GEODE-8618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-8618:
-
Summary: OQL grammar specification in docs is incomplete (was: OQL Grammar
specification in docs is incomplete)
> OQL grammar specification in docs is incomplete
> ---
>
> Key: GEODE-8618
> URL: https://issues.apache.org/jira/browse/GEODE-8618
> Project: Geode
> Issue Type: Improvement
> Components: querying
>Affects Versions: 1.11.0, 1.12.0, 1.13.0
>Reporter: John Blum
>Priority: Minor
>
> For example, there are no rules for the {{ORDER BY}} and {{LIMIT}} clauses.
> Referring to this section in the docs:
> https://geode.apache.org/docs/guide/113/developing/querying_basics/query_grammar_and_reserved_words.html
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8286) The Geode JVM Shutdown Hook should not be enabled by default
[ https://issues.apache.org/jira/browse/GEODE-8286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Blum updated GEODE-8286: - Priority: Critical (was: Minor) > The Geode JVM Shutdown Hook should not be enabled by default > > > Key: GEODE-8286 > URL: https://issues.apache.org/jira/browse/GEODE-8286 > Project: Geode > Issue Type: Improvement > Components: configuration, general, management >Reporter: John Blum >Priority: Critical > Labels: JSON-PDX > > Apache Geode registers a JVM Shutdown Hook in > [InternalDistributedSystem|https://github.com/apache/geode/blob/rel/v1.12.0/geode-core/src/main/java/org/apache/geode/distributed/internal/InternalDistributedSystem.java#L2190-L] > that ensures the Apache Geode Cache and associated DistributedSystem are > shutdown properly when the JVM exits. > However, this JVM Shutdown Hook and interfere with Frameworks and Tooling > that have their own Lifecycle Management capabilities. The Spring Framework > and Container is one such example. > Any managed environment, be that Micronaut, Quarkus, Pivotal Platform > (PCF/TAS), Kubernetes, AWS, Azure, GCP, etc, etc, are going to have lifecycle > management capabilities. > It is very important that the environment manage the lifecycle of all actors > in the fully "integrated" system. > In Spring's case, it must coordinate the lifecycle of application components > along with integrated systems, like Geode, in an effort to shut all > components down in a coordinated, correct fashion. > If Geode's JVM Shutdown Hook is permitted to do as it pleases, then this can > circumvent the Framework/Container, Tool, or other's lifecycle management > capabilities, leaving the system or application in an inconsistent/incorrect > state. > To make matters worse, the [JVM System > Property|https://github.com/apache/geode/blob/rel/v1.12.0/geode-core/src/main/java/org/apache/geode/distributed/internal/InternalDistributedSystem.java#L2191] > (and specifically, > [this|https://github.com/apache/geode/blob/rel/v1.12.0/geode-core/src/main/java/org/apache/geode/distributed/internal/InternalDistributedSystem.java#L391-L392]) > controlling the enablement of the JVM Shutdown Hook, is non-public and [not > documented|https://geode.apache.org/docs/guide/112/reference/topics/gemfire_properties.html]. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8618) OQL Grammar specification in docs is incomplete
[
https://issues.apache.org/jira/browse/GEODE-8618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-8618:
-
Priority: Minor (was: Major)
> OQL Grammar specification in docs is incomplete
> ---
>
> Key: GEODE-8618
> URL: https://issues.apache.org/jira/browse/GEODE-8618
> Project: Geode
> Issue Type: Improvement
> Components: querying
>Affects Versions: 1.11.0, 1.12.0, 1.13.0
>Reporter: John Blum
>Priority: Minor
>
> For example, there are no rules for the {{ORDER BY}} and {{LIMIT}} clauses.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8618) OQL Grammar specification in docs is incomplete
[
https://issues.apache.org/jira/browse/GEODE-8618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-8618:
-
Description:
For example, there are no rules for the {{ORDER BY}} and {{LIMIT}} clauses.
Referring to this section in the docs:
https://geode.apache.org/docs/guide/113/developing/querying_basics/query_grammar_and_reserved_words.html
was:For example, there are no rules for the {{ORDER BY}} and {{LIMIT}}
clauses.
> OQL Grammar specification in docs is incomplete
> ---
>
> Key: GEODE-8618
> URL: https://issues.apache.org/jira/browse/GEODE-8618
> Project: Geode
> Issue Type: Improvement
> Components: querying
>Affects Versions: 1.11.0, 1.12.0, 1.13.0
>Reporter: John Blum
>Priority: Minor
>
> For example, there are no rules for the {{ORDER BY}} and {{LIMIT}} clauses.
> Referring to this section in the docs:
> https://geode.apache.org/docs/guide/113/developing/querying_basics/query_grammar_and_reserved_words.html
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8286) The Geode JVM Shutdown Hook should not be enabled by default
[ https://issues.apache.org/jira/browse/GEODE-8286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Blum updated GEODE-8286: - Priority: Minor (was: Major) > The Geode JVM Shutdown Hook should not be enabled by default > > > Key: GEODE-8286 > URL: https://issues.apache.org/jira/browse/GEODE-8286 > Project: Geode > Issue Type: Improvement > Components: configuration, general, management >Reporter: John Blum >Priority: Minor > Labels: JSON-PDX > > Apache Geode registers a JVM Shutdown Hook in > [InternalDistributedSystem|https://github.com/apache/geode/blob/rel/v1.12.0/geode-core/src/main/java/org/apache/geode/distributed/internal/InternalDistributedSystem.java#L2190-L] > that ensures the Apache Geode Cache and associated DistributedSystem are > shutdown properly when the JVM exits. > However, this JVM Shutdown Hook and interfere with Frameworks and Tooling > that have their own Lifecycle Management capabilities. The Spring Framework > and Container is one such example. > Any managed environment, be that Micronaut, Quarkus, Pivotal Platform > (PCF/TAS), Kubernetes, AWS, Azure, GCP, etc, etc, are going to have lifecycle > management capabilities. > It is very important that the environment manage the lifecycle of all actors > in the fully "integrated" system. > In Spring's case, it must coordinate the lifecycle of application components > along with integrated systems, like Geode, in an effort to shut all > components down in a coordinated, correct fashion. > If Geode's JVM Shutdown Hook is permitted to do as it pleases, then this can > circumvent the Framework/Container, Tool, or other's lifecycle management > capabilities, leaving the system or application in an inconsistent/incorrect > state. > To make matters worse, the [JVM System > Property|https://github.com/apache/geode/blob/rel/v1.12.0/geode-core/src/main/java/org/apache/geode/distributed/internal/InternalDistributedSystem.java#L2191] > (and specifically, > [this|https://github.com/apache/geode/blob/rel/v1.12.0/geode-core/src/main/java/org/apache/geode/distributed/internal/InternalDistributedSystem.java#L391-L392]) > controlling the enablement of the JVM Shutdown Hook, is non-public and [not > documented|https://geode.apache.org/docs/guide/112/reference/topics/gemfire_properties.html]. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8618) OQL Grammar specification in docs is incomplete
John Blum created GEODE-8618:
Summary: OQL Grammar specification in docs is incomplete
Key: GEODE-8618
URL: https://issues.apache.org/jira/browse/GEODE-8618
Project: Geode
Issue Type: Improvement
Components: querying
Affects Versions: 1.13.0, 1.12.0, 1.11.0
Reporter: John Blum
For example, there are no rules for the {{ORDER BY}} and {{LIMIT}} clauses.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8585) Redis SCAN, HSCAN, and SSCAN do not detect illegal parameters
[
https://issues.apache.org/jira/browse/GEODE-8585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17214995#comment-17214995
]
ASF GitHub Bot commented on GEODE-8585:
---
jdeppe-pivotal commented on a change in pull request #5627:
URL: https://github.com/apache/geode/pull/5627#discussion_r505827527
##
File path:
geode-redis/src/main/java/org/apache/geode/redis/internal/executor/key/ScanExecutor.java
##
@@ -36,91 +39,87 @@
public RedisResponse executeCommand(Command command, ExecutionHandlerContext
context) {
List commandElems = command.getProcessedCommand();
-if (commandElems.size() < 2) {
- return RedisResponse.error(ArityDef.SCAN);
-}
-
String cursorString = command.getStringKey();
-int cursor = 0;
-Pattern matchPattern = null;
-String globMatchString = null;
+BigInteger cursor;
+Pattern matchPattern;
+String globPattern = null;
int count = DEFAULT_COUNT;
+
try {
- cursor = Integer.parseInt(cursorString);
+ cursor = new BigInteger(cursorString).abs();
} catch (NumberFormatException e) {
return RedisResponse.error(ERROR_CURSOR);
}
-if (cursor < 0) {
+
+if (cursor.compareTo(UNSIGNED_LONG_CAPACITY) > 0) {
return RedisResponse.error(ERROR_CURSOR);
}
-if (commandElems.size() > 3) {
- try {
-byte[] bytes = commandElems.get(2);
-String tmp = Coder.bytesToString(bytes);
-if (tmp.equalsIgnoreCase("MATCH")) {
- bytes = commandElems.get(3);
- globMatchString = Coder.bytesToString(bytes);
-} else if (tmp.equalsIgnoreCase("COUNT")) {
- bytes = commandElems.get(3);
- count = Coder.bytesToInt(bytes);
-}
- } catch (NumberFormatException e) {
-return RedisResponse.error(ERROR_COUNT);
- }
+if (!cursor.equals(context.getScanCursor())) {
+ cursor = new BigInteger("0");
}
-if (commandElems.size() > 5) {
- try {
-byte[] bytes = commandElems.get(4);
-String tmp = Coder.bytesToString(bytes);
-if (tmp.equalsIgnoreCase("COUNT")) {
- bytes = commandElems.get(5);
- count = Coder.bytesToInt(bytes);
+for (int i = 2; i < commandElems.size(); i = i + 2) {
+ byte[] commandElemBytes = commandElems.get(i);
+ String keyword = Coder.bytesToString(commandElemBytes);
+ if (keyword.equalsIgnoreCase("MATCH")) {
+commandElemBytes = commandElems.get(i + 1);
+globPattern = Coder.bytesToString(commandElemBytes);
+
+ } else if (keyword.equalsIgnoreCase("COUNT")) {
+commandElemBytes = commandElems.get(i + 1);
+try {
+ count = Coder.bytesToInt(commandElemBytes);
+} catch (NumberFormatException e) {
+ return RedisResponse.error(ERROR_NOT_INTEGER);
+}
+
+if (count < 1) {
+ return RedisResponse.error(ERROR_SYNTAX);
}
- } catch (NumberFormatException e) {
-return RedisResponse.error(ERROR_COUNT);
- }
-}
-if (count < 0) {
- return RedisResponse.error(ERROR_COUNT);
+ } else {
+return RedisResponse.error(ERROR_SYNTAX);
+ }
}
try {
- matchPattern = convertGlobToRegex(globMatchString);
+ matchPattern = convertGlobToRegex(globPattern);
} catch (PatternSyntaxException e) {
- return RedisResponse.error(ERROR_ILLEGAL_GLOB);
+ LogService.getLogger().warn(
+ "Could not compile the pattern: '{}' due to the following exception:
'{}'. SCAN will return an empty list.",
+ globPattern, e.getMessage());
+ return RedisResponse.emptyScan();
}
-List returnList = getIteration(getDataRegion(context).keySet(),
matchPattern, count,
+List returnList = scan(getDataRegion(context).keySet(),
matchPattern, count,
cursor);
+context.setScanCursor(new BigInteger((String) returnList.get(0)));
return RedisResponse.scan(returnList);
}
- private List getIteration(Collection list, Pattern
matchPattern,
- int count, int cursor) {
-List returnList = new ArrayList<>();
+ private List scan(Collection list, Pattern
matchPattern,
Review comment:
I think it would be better to have this return a `Pair>` - that way it's not hiding the fact that the zero-th element is
special.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Redis SCAN, HSCAN, and SSCAN do not detect illegal parameters
> -
>
> Key: GEODE-8585
> URL: https://issues.apache.org/jira/browse/GEODE-8585
> Project:
[jira] [Commented] (GEODE-4650) DLockService.clearGrantor can potentially hang
[
https://issues.apache.org/jira/browse/GEODE-4650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17214992#comment-17214992
]
Geode Integration commented on GEODE-4650:
--
Seen in [UpgradeTestOpenJDK11
#80|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-12-main/jobs/UpgradeTestOpenJDK11/builds/80].
> DLockService.clearGrantor can potentially hang
> --
>
> Key: GEODE-4650
> URL: https://issues.apache.org/jira/browse/GEODE-4650
> Project: Geode
> Issue Type: Bug
> Components: distributed lock service
>Reporter: Jason Huynh
>Priority: Major
> Labels: pull-request-available, swat
> Fix For: 1.8.0
>
> Attachments: callstacks-2018-02-10-05-25-15.txt,
> callstacks-2018-02-10-05-25-23.txt, callstacks-2018-02-10-05-25-30.txt
>
> Time Spent: 6h 20m
> Remaining Estimate: 0h
>
> There was a test run in the precheckin pipeline that hung with the following
> stack:
>
> {code:java}
> "RMI TCP Connection(1)-172.17.0.3" #30 daemon prio=5 os_prio=0
> tid=0x7f4560001800 nid=0x191 waiting on condition [0x7f45771c]
> java.lang.Thread.State: TIMED_WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0xe082d298> (a
> java.util.concurrent.CountDownLatch$Sync)
> 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:64)
> 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)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:853)
> at
> org.apache.geode.distributed.internal.locks.ElderInitProcessor.init(ElderInitProcessor.java:72)
> at
> org.apache.geode.distributed.internal.locks.ElderState.(ElderState.java:56)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.getElderStateWithTryLock(ClusterDistributionManager.java:3359)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.getElderState(ClusterDistributionManager.java:3309)
> at
> org.apache.geode.distributed.internal.locks.GrantorRequestProcessor.startElderCall(GrantorRequestProcessor.java:238)
> at
> org.apache.geode.distributed.internal.locks.GrantorRequestProcessor.basicOp(GrantorRequestProcessor.java:347)
> at
> org.apache.geode.distributed.internal.locks.GrantorRequestProcessor.basicOp(GrantorRequestProcessor.java:327)
> at
> org.apache.geode.distributed.internal.locks.GrantorRequestProcessor.clearGrantor(GrantorRequestProcessor.java:318)
> at
> org.apache.geode.distributed.internal.locks.DLockService.clearGrantor(DLockService.java:872)
> at
> org.apache.geode.distributed.internal.locks.DLockGrantor.destroy(DLockGrantor.java:1227)
> - locked <0xe0837ff0> (a
> org.apache.geode.distributed.internal.locks.DLockGrantor)
> at
> org.apache.geode.distributed.internal.locks.DLockService.nullLockGrantorId(DLockService.java:646)
> at
> org.apache.geode.distributed.internal.locks.DLockService.basicDestroy(DLockService.java:2358)
> at
> org.apache.geode.distributed.internal.locks.DLockService.destroyAndRemove(DLockService.java:2276)
> - locked <0xe05c7468> (a java.lang.Object)
> at
> org.apache.geode.distributed.internal.locks.DLockService.destroyServiceNamed(DLockService.java:2214)
> at
> org.apache.geode.distributed.DistributedLockService.destroy(DistributedLockService.java:84)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.destroyGatewaySenderLockService(GemFireCacheImpl.java:2043)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.close(GemFireCacheImpl.java:2180)
> - locked <0xe04653e0> (a java.lang.Class for
> org.apache.geode.internal.cache.GemFireCacheImpl)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.close(GemFireCacheImpl.java:1960)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.close(GemFireCacheImpl.java:1950)
> at
> org.apache.geode.test.junit.rules.ServerStarterRule.stopMember(ServerStarterRule.java:99)
> at
> org.apache.geode.test.junit.rules.MemberStarterRule.after(MemberStarterRule.java:81)
> at
>
[jira] [Updated] (GEODE-7696) Add comment to GMSHealthMonitor explaining when IllegalStateException may be thrown
[
https://issues.apache.org/jira/browse/GEODE-7696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kamilla Aslami updated GEODE-7696:
--
Summary: Add comment to GMSHealthMonitor explaining when
IllegalStateException may be thrown (was: Remove unecessary catch block from
GMSHealthMonitor.java)
> Add comment to GMSHealthMonitor explaining when IllegalStateException may be
> thrown
> ---
>
> Key: GEODE-7696
> URL: https://issues.apache.org/jira/browse/GEODE-7696
> Project: Geode
> Issue Type: Improvement
> Components: membership
>Reporter: Ernest Burghardt
>Assignee: Kamilla Aslami
>Priority: Major
> Labels: pull-request-available
>
> former:
> {code:java}
> } catch (IllegalStateException \| GemFireConfigException e) {
> {code}
> current:
> {code:java}
> } catch (IllegalStateException e) {
> {code}
> we can let both bubble up...
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8612) Remove unused Redis constants
[ https://issues.apache.org/jira/browse/GEODE-8612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17214959#comment-17214959 ] ASF subversion and git services commented on GEODE-8612: Commit 4c4820207e263f1a9d11f34df5cd6cd2f9daf973 in geode's branch refs/heads/develop from Sarah [ https://gitbox.apache.org/repos/asf?p=geode.git;h=4c48202 ] GEODE-8612: Remove unused Redis constants (#5628) > Remove unused Redis constants > - > > Key: GEODE-8612 > URL: https://issues.apache.org/jira/browse/GEODE-8612 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Sarah Abbey >Assignee: Sarah Abbey >Priority: Trivial > Labels: pull-request-available > > Remove constants we no longer use in `RedisConstants` -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8612) Remove unused Redis constants
[ https://issues.apache.org/jira/browse/GEODE-8612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17214952#comment-17214952 ] ASF GitHub Bot commented on GEODE-8612: --- sabbey37 merged pull request #5628: URL: https://github.com/apache/geode/pull/5628 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Remove unused Redis constants > - > > Key: GEODE-8612 > URL: https://issues.apache.org/jira/browse/GEODE-8612 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Sarah Abbey >Assignee: Sarah Abbey >Priority: Trivial > Labels: pull-request-available > > Remove constants we no longer use in `RedisConstants` -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (GEODE-7696) Remove unecessary catch block from GMSHealthMonitor.java
[
https://issues.apache.org/jira/browse/GEODE-7696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17214924#comment-17214924
]
Kamilla Aslami edited comment on GEODE-7696 at 10/15/20, 6:56 PM:
--
It turns out that the catch block is necessary to catch IllegalStateException
that may be thrown if ConnectTimeoutTask is scheduled on a timer that was
already canceled. Once a timer has been terminated, no more tasks may be
scheduled on it.
{code:java}
ERROR util.TestException: Got unexpected exception
java.lang.IllegalStateException: Timer already cancelled.
at java.util.Timer.sched(Timer.java:397)
at java.util.Timer.schedule(Timer.java:193)
at
org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor$ConnectTimeoutTask.beforeConnect(GMSHealthMonitor.java:1494)
at
org.apache.geode.distributed.internal.tcpserver.AdvancedSocketCreatorImpl.connect(AdvancedSocketCreatorImpl.java:98)
at
org.apache.geode.internal.net.SCAdvancedSocketCreator.connect(SCAdvancedSocketCreator.java:51)
at
org.apache.geode.distributed.internal.tcpserver.AdvancedSocketCreatorImpl.connect(AdvancedSocketCreatorImpl.java:72)
at
org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.doTCPCheckMember(GMSHealthMonitor.java:578)
at
org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.inlineCheckIfAvailable(GMSHealthMonitor.java:1377)
at
org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.checkIfAvailable(GMSHealthMonitor.java:663)
at
org.apache.geode.distributed.internal.membership.gms.GMSMembership.verifyMember(GMSMembership.java:1363)
at
org.apache.geode.distributed.internal.membership.gms.GMSMembership.suspectMembers(GMSMembership.java:1337)
at
org.apache.geode.distributed.internal.DistributionImpl.suspectMembers(DistributionImpl.java:557)
at
org.apache.geode.distributed.internal.ReplyProcessor21.timeout(ReplyProcessor21.java:1113)
at
org.apache.geode.distributed.internal.ReplyProcessor21.basicWait(ReplyProcessor21.java:687)
at
org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:794)
at
org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:771)
at
org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:857)
at
org.apache.geode.internal.cache.DistributedCacheOperation.waitForAckIfNeeded(DistributedCacheOperation.java:779)
at
org.apache.geode.internal.cache.DistributedCacheOperation._distribute(DistributedCacheOperation.java:676)
at
org.apache.geode.internal.cache.DistributedCacheOperation.startOperation(DistributedCacheOperation.java:277)
at
org.apache.geode.internal.cache.DistributedCacheOperation.distribute(DistributedCacheOperation.java:318)
at
org.apache.geode.internal.cache.DistributedRegion.distributeUpdate(DistributedRegion.java:520)
at
org.apache.geode.internal.cache.DistributedRegion.basicPutPart3(DistributedRegion.java:498)
at
org.apache.geode.internal.cache.map.RegionMapPut.doAfterCompletionActions(RegionMapPut.java:307)
at
org.apache.geode.internal.cache.map.AbstractRegionMapPut.doPut(AbstractRegionMapPut.java:185)
at
org.apache.geode.internal.cache.map.AbstractRegionMapPut.runWhileLockedForCacheModification(AbstractRegionMapPut.java:119)
at
org.apache.geode.internal.cache.map.RegionMapPut.runWhileLockedForCacheModification(RegionMapPut.java:161)
at
org.apache.geode.internal.cache.map.AbstractRegionMapPut.put(AbstractRegionMapPut.java:169)
at
org.apache.geode.internal.cache.AbstractRegionMap.basicPut(AbstractRegionMap.java:2044)
at
org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5599)
at
org.apache.geode.internal.cache.DistributedRegion.virtualPut(DistributedRegion.java:393)
at
org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5577)
at
org.apache.geode.internal.cache.LocalRegionDataView.putEntry(LocalRegionDataView.java:157)
at org.apache.geode.internal.cache.LocalRegion.basicPut(LocalRegion.java:5035)
at
org.apache.geode.internal.cache.LocalRegion.validatedPut(LocalRegion.java:1635)
at org.apache.geode.internal.cache.LocalRegion.put(LocalRegion.java:1622){code}
The catch block was added as a fix for GEODE-1321.
Instead of removing it, I will add a comment explaining when the exception may
be thrown.
was (Author: kaslami):
It turns out that the catch block is necessary to catch IllegalStateException
that may be thrown if ConnectTimeoutTask is scheduled on a timer that was
already canceled. Once a timer has been terminated, no more tasks may be
scheduled on it.
{code:java}
ERROR util.TestException: Got unexpected exception
java.lang.IllegalStateException: Timer already cancelled.
at java.util.Timer.sched(Timer.java:397)
at java.util.Timer.schedule(Timer.java:193)
at
[jira] [Commented] (GEODE-7696) Remove unecessary catch block from GMSHealthMonitor.java
[
https://issues.apache.org/jira/browse/GEODE-7696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17214924#comment-17214924
]
Kamilla Aslami commented on GEODE-7696:
---
It turns out that the catch block is necessary to catch IllegalStateException
that may be thrown if ConnectTimeoutTask is scheduled on a timer that was
already canceled. Once a timer has been terminated, no more tasks may be
scheduled on it.
{code:java}
ERROR util.TestException: Got unexpected exception
java.lang.IllegalStateException: Timer already cancelled.
at java.util.Timer.sched(Timer.java:397)
at java.util.Timer.schedule(Timer.java:193)
at
org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor$ConnectTimeoutTask.beforeConnect(GMSHealthMonitor.java:1494)
at
org.apache.geode.distributed.internal.tcpserver.AdvancedSocketCreatorImpl.connect(AdvancedSocketCreatorImpl.java:98)
at
org.apache.geode.internal.net.SCAdvancedSocketCreator.connect(SCAdvancedSocketCreator.java:51)
at
org.apache.geode.distributed.internal.tcpserver.AdvancedSocketCreatorImpl.connect(AdvancedSocketCreatorImpl.java:72)
at
org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.doTCPCheckMember(GMSHealthMonitor.java:578)
at
org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.inlineCheckIfAvailable(GMSHealthMonitor.java:1377)
at
org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.checkIfAvailable(GMSHealthMonitor.java:663)
at
org.apache.geode.distributed.internal.membership.gms.GMSMembership.verifyMember(GMSMembership.java:1363)
at
org.apache.geode.distributed.internal.membership.gms.GMSMembership.suspectMembers(GMSMembership.java:1337)
at
org.apache.geode.distributed.internal.DistributionImpl.suspectMembers(DistributionImpl.java:557)
at
org.apache.geode.distributed.internal.ReplyProcessor21.timeout(ReplyProcessor21.java:1113)
at
org.apache.geode.distributed.internal.ReplyProcessor21.basicWait(ReplyProcessor21.java:687)
at
org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:794)
at
org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:771)
at
org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:857)
at
org.apache.geode.internal.cache.DistributedCacheOperation.waitForAckIfNeeded(DistributedCacheOperation.java:779)
at
org.apache.geode.internal.cache.DistributedCacheOperation._distribute(DistributedCacheOperation.java:676)
at
org.apache.geode.internal.cache.DistributedCacheOperation.startOperation(DistributedCacheOperation.java:277)
at
org.apache.geode.internal.cache.DistributedCacheOperation.distribute(DistributedCacheOperation.java:318)
at
org.apache.geode.internal.cache.DistributedRegion.distributeUpdate(DistributedRegion.java:520)
at
org.apache.geode.internal.cache.DistributedRegion.basicPutPart3(DistributedRegion.java:498)
at
org.apache.geode.internal.cache.map.RegionMapPut.doAfterCompletionActions(RegionMapPut.java:307)
at
org.apache.geode.internal.cache.map.AbstractRegionMapPut.doPut(AbstractRegionMapPut.java:185)
at
org.apache.geode.internal.cache.map.AbstractRegionMapPut.runWhileLockedForCacheModification(AbstractRegionMapPut.java:119)
at
org.apache.geode.internal.cache.map.RegionMapPut.runWhileLockedForCacheModification(RegionMapPut.java:161)
at
org.apache.geode.internal.cache.map.AbstractRegionMapPut.put(AbstractRegionMapPut.java:169)
at
org.apache.geode.internal.cache.AbstractRegionMap.basicPut(AbstractRegionMap.java:2044)
at
org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5599)
at
org.apache.geode.internal.cache.DistributedRegion.virtualPut(DistributedRegion.java:393)
at
org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5577)
at
org.apache.geode.internal.cache.LocalRegionDataView.putEntry(LocalRegionDataView.java:157)
at org.apache.geode.internal.cache.LocalRegion.basicPut(LocalRegion.java:5035)
at
org.apache.geode.internal.cache.LocalRegion.validatedPut(LocalRegion.java:1635)
at org.apache.geode.internal.cache.LocalRegion.put(LocalRegion.java:1622)
at splitBrain.ForcedDiscTest.addEntry(ForcedDiscTest.java:390){code}
The catch block was added as a fix for GEODE-1321.
Instead of removing it, I will add a comment explaining when the exception may
be thrown.
> Remove unecessary catch block from GMSHealthMonitor.java
>
>
> Key: GEODE-7696
> URL: https://issues.apache.org/jira/browse/GEODE-7696
> Project: Geode
> Issue Type: Improvement
> Components: membership
>Reporter: Ernest Burghardt
>Assignee: Kamilla Aslami
>Priority: Major
> Labels: pull-request-available
>
> former:
>
[jira] [Commented] (GEODE-8536) StackOverflow can occur when Lucene IndexWriter is unable to be created
[
https://issues.apache.org/jira/browse/GEODE-8536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17214922#comment-17214922
]
ASF subversion and git services commented on GEODE-8536:
Commit d2c1d67fd0010c208c320e41a1ef8d6e44710bd1 in geode's branch
refs/heads/develop from Donal Evans
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=d2c1d67 ]
GEODE-8536: Allow limited retries when creating Lucene IndexWriter (#5589)
GEODE-8536: Allow limited retries when creating Lucene IndexWriter
Authored-by: Donal Evans
> StackOverflow can occur when Lucene IndexWriter is unable to be created
> ---
>
> Key: GEODE-8536
> URL: https://issues.apache.org/jira/browse/GEODE-8536
> Project: Geode
> Issue Type: Bug
> Components: functions, lucene
>Affects Versions: 1.12.0, 1.13.0, 1.14.0
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
> Labels: pull-request-available
>
> If, during a call to IndexRepositoryFactory.computeIndexRepository(), an
> IOException is encountered when attempting to construct an IndexWriter, the
> function retry logic will reattempt the execution. This allows transient
> exceptions caused by concurrent modification of the fileAndChunk region to be
> ignored and subsequent executions to succeed (see GEODE-7703). However, if
> the IOException is consistently thrown, the infinitely retrying function can
> cause a StackOverflow:
> {noformat}
> java.lang.StackOverflowError
> at
> org.apache.geode.SystemFailure.startWatchDog(SystemFailure.java:320)
> at
> org.apache.geode.SystemFailure.notifyWatchDog(SystemFailure.java:758)
> at org.apache.geode.SystemFailure.setFailure(SystemFailure.java:813)
> at
> org.apache.geode.SystemFailure.initiateFailure(SystemFailure.java:790)
> at
> org.apache.geode.internal.InternalDataSerializer.invokeToData(InternalDataSerializer.java:2251)
> at
> org.apache.geode.internal.InternalDataSerializer.basicWriteObject(InternalDataSerializer.java:2031)
> at
> org.apache.geode.DataSerializer.writeObject(DataSerializer.java:2839)
> at
> org.apache.geode.internal.cache.partitioned.PartitionedRegionFunctionStreamingMessage.toData(PartitionedRegionFunctionStreamingMessage.java:192)
> at
> org.apache.geode.internal.serialization.internal.DSFIDSerializerImpl.invokeToData(DSFIDSerializerImpl.java:213)
> at
> org.apache.geode.internal.serialization.internal.DSFIDSerializerImpl.write(DSFIDSerializerImpl.java:137)
> at
> org.apache.geode.internal.InternalDataSerializer.writeDSFID(InternalDataSerializer.java:1484)
> at
> org.apache.geode.internal.tcp.MsgStreamer.writeMessage(MsgStreamer.java:247)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:306)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:182)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:511)
> at
> org.apache.geode.distributed.internal.DistributionImpl.directChannelSend(DistributionImpl.java:346)
> at
> org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:291)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2058)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:1986)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendMessage(ClusterDistributionManager.java:2023)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.putOutgoing(ClusterDistributionManager.java:1083)
> at
> org.apache.geode.internal.cache.execute.PartitionedRegionFunctionResultWaiter.getPartitionedDataFrom(PartitionedRegionFunctionResultWaiter.java:89)
> at
> org.apache.geode.internal.cache.PartitionedRegion.executeOnAllBuckets(PartitionedRegion.java:4079)
> at
> org.apache.geode.internal.cache.PartitionedRegion.executeFunction(PartitionedRegion.java:3583)
> at
> org.apache.geode.internal.cache.execute.PartitionedRegionFunctionExecutor.executeFunction(PartitionedRegionFunctionExecutor.java:220)
> at
> org.apache.geode.internal.cache.execute.AbstractExecution.execute(AbstractExecution.java:376)
> at
> org.apache.geode.internal.cache.execute.AbstractExecution.execute(AbstractExecution.java:359)
> at
> org.apache.geode.internal.cache.execute.LocalResultCollectorImpl.getResultInternal(LocalResultCollectorImpl.java:139)
> at
>
[jira] [Commented] (GEODE-8536) StackOverflow can occur when Lucene IndexWriter is unable to be created
[
https://issues.apache.org/jira/browse/GEODE-8536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17214921#comment-17214921
]
ASF subversion and git services commented on GEODE-8536:
Commit d2c1d67fd0010c208c320e41a1ef8d6e44710bd1 in geode's branch
refs/heads/develop from Donal Evans
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=d2c1d67 ]
GEODE-8536: Allow limited retries when creating Lucene IndexWriter (#5589)
GEODE-8536: Allow limited retries when creating Lucene IndexWriter
Authored-by: Donal Evans
> StackOverflow can occur when Lucene IndexWriter is unable to be created
> ---
>
> Key: GEODE-8536
> URL: https://issues.apache.org/jira/browse/GEODE-8536
> Project: Geode
> Issue Type: Bug
> Components: functions, lucene
>Affects Versions: 1.12.0, 1.13.0, 1.14.0
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
> Labels: pull-request-available
>
> If, during a call to IndexRepositoryFactory.computeIndexRepository(), an
> IOException is encountered when attempting to construct an IndexWriter, the
> function retry logic will reattempt the execution. This allows transient
> exceptions caused by concurrent modification of the fileAndChunk region to be
> ignored and subsequent executions to succeed (see GEODE-7703). However, if
> the IOException is consistently thrown, the infinitely retrying function can
> cause a StackOverflow:
> {noformat}
> java.lang.StackOverflowError
> at
> org.apache.geode.SystemFailure.startWatchDog(SystemFailure.java:320)
> at
> org.apache.geode.SystemFailure.notifyWatchDog(SystemFailure.java:758)
> at org.apache.geode.SystemFailure.setFailure(SystemFailure.java:813)
> at
> org.apache.geode.SystemFailure.initiateFailure(SystemFailure.java:790)
> at
> org.apache.geode.internal.InternalDataSerializer.invokeToData(InternalDataSerializer.java:2251)
> at
> org.apache.geode.internal.InternalDataSerializer.basicWriteObject(InternalDataSerializer.java:2031)
> at
> org.apache.geode.DataSerializer.writeObject(DataSerializer.java:2839)
> at
> org.apache.geode.internal.cache.partitioned.PartitionedRegionFunctionStreamingMessage.toData(PartitionedRegionFunctionStreamingMessage.java:192)
> at
> org.apache.geode.internal.serialization.internal.DSFIDSerializerImpl.invokeToData(DSFIDSerializerImpl.java:213)
> at
> org.apache.geode.internal.serialization.internal.DSFIDSerializerImpl.write(DSFIDSerializerImpl.java:137)
> at
> org.apache.geode.internal.InternalDataSerializer.writeDSFID(InternalDataSerializer.java:1484)
> at
> org.apache.geode.internal.tcp.MsgStreamer.writeMessage(MsgStreamer.java:247)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:306)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:182)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:511)
> at
> org.apache.geode.distributed.internal.DistributionImpl.directChannelSend(DistributionImpl.java:346)
> at
> org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:291)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2058)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:1986)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendMessage(ClusterDistributionManager.java:2023)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.putOutgoing(ClusterDistributionManager.java:1083)
> at
> org.apache.geode.internal.cache.execute.PartitionedRegionFunctionResultWaiter.getPartitionedDataFrom(PartitionedRegionFunctionResultWaiter.java:89)
> at
> org.apache.geode.internal.cache.PartitionedRegion.executeOnAllBuckets(PartitionedRegion.java:4079)
> at
> org.apache.geode.internal.cache.PartitionedRegion.executeFunction(PartitionedRegion.java:3583)
> at
> org.apache.geode.internal.cache.execute.PartitionedRegionFunctionExecutor.executeFunction(PartitionedRegionFunctionExecutor.java:220)
> at
> org.apache.geode.internal.cache.execute.AbstractExecution.execute(AbstractExecution.java:376)
> at
> org.apache.geode.internal.cache.execute.AbstractExecution.execute(AbstractExecution.java:359)
> at
> org.apache.geode.internal.cache.execute.LocalResultCollectorImpl.getResultInternal(LocalResultCollectorImpl.java:139)
> at
>
[jira] [Commented] (GEODE-8536) StackOverflow can occur when Lucene IndexWriter is unable to be created
[
https://issues.apache.org/jira/browse/GEODE-8536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17214920#comment-17214920
]
ASF GitHub Bot commented on GEODE-8536:
---
DonalEvans merged pull request #5589:
URL: https://github.com/apache/geode/pull/5589
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> StackOverflow can occur when Lucene IndexWriter is unable to be created
> ---
>
> Key: GEODE-8536
> URL: https://issues.apache.org/jira/browse/GEODE-8536
> Project: Geode
> Issue Type: Bug
> Components: functions, lucene
>Affects Versions: 1.12.0, 1.13.0, 1.14.0
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
> Labels: pull-request-available
>
> If, during a call to IndexRepositoryFactory.computeIndexRepository(), an
> IOException is encountered when attempting to construct an IndexWriter, the
> function retry logic will reattempt the execution. This allows transient
> exceptions caused by concurrent modification of the fileAndChunk region to be
> ignored and subsequent executions to succeed (see GEODE-7703). However, if
> the IOException is consistently thrown, the infinitely retrying function can
> cause a StackOverflow:
> {noformat}
> java.lang.StackOverflowError
> at
> org.apache.geode.SystemFailure.startWatchDog(SystemFailure.java:320)
> at
> org.apache.geode.SystemFailure.notifyWatchDog(SystemFailure.java:758)
> at org.apache.geode.SystemFailure.setFailure(SystemFailure.java:813)
> at
> org.apache.geode.SystemFailure.initiateFailure(SystemFailure.java:790)
> at
> org.apache.geode.internal.InternalDataSerializer.invokeToData(InternalDataSerializer.java:2251)
> at
> org.apache.geode.internal.InternalDataSerializer.basicWriteObject(InternalDataSerializer.java:2031)
> at
> org.apache.geode.DataSerializer.writeObject(DataSerializer.java:2839)
> at
> org.apache.geode.internal.cache.partitioned.PartitionedRegionFunctionStreamingMessage.toData(PartitionedRegionFunctionStreamingMessage.java:192)
> at
> org.apache.geode.internal.serialization.internal.DSFIDSerializerImpl.invokeToData(DSFIDSerializerImpl.java:213)
> at
> org.apache.geode.internal.serialization.internal.DSFIDSerializerImpl.write(DSFIDSerializerImpl.java:137)
> at
> org.apache.geode.internal.InternalDataSerializer.writeDSFID(InternalDataSerializer.java:1484)
> at
> org.apache.geode.internal.tcp.MsgStreamer.writeMessage(MsgStreamer.java:247)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:306)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:182)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:511)
> at
> org.apache.geode.distributed.internal.DistributionImpl.directChannelSend(DistributionImpl.java:346)
> at
> org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:291)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2058)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:1986)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendMessage(ClusterDistributionManager.java:2023)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.putOutgoing(ClusterDistributionManager.java:1083)
> at
> org.apache.geode.internal.cache.execute.PartitionedRegionFunctionResultWaiter.getPartitionedDataFrom(PartitionedRegionFunctionResultWaiter.java:89)
> at
> org.apache.geode.internal.cache.PartitionedRegion.executeOnAllBuckets(PartitionedRegion.java:4079)
> at
> org.apache.geode.internal.cache.PartitionedRegion.executeFunction(PartitionedRegion.java:3583)
> at
> org.apache.geode.internal.cache.execute.PartitionedRegionFunctionExecutor.executeFunction(PartitionedRegionFunctionExecutor.java:220)
> at
> org.apache.geode.internal.cache.execute.AbstractExecution.execute(AbstractExecution.java:376)
> at
> org.apache.geode.internal.cache.execute.AbstractExecution.execute(AbstractExecution.java:359)
> at
> org.apache.geode.internal.cache.execute.LocalResultCollectorImpl.getResultInternal(LocalResultCollectorImpl.java:139)
> at
>
[jira] [Commented] (GEODE-8617) org.apache.geode.test.dunit.VM.bounce() fails to restart VM with different Geode version due to EOFException
[
https://issues.apache.org/jira/browse/GEODE-8617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17214918#comment-17214918
]
Geode Integration commented on GEODE-8617:
--
Seen in [UpgradeTestOpenJDK8
#75|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-12-main/jobs/UpgradeTestOpenJDK8/builds/75].
> org.apache.geode.test.dunit.VM.bounce() fails to restart VM with different
> Geode version due to EOFException
>
>
> Key: GEODE-8617
> URL: https://issues.apache.org/jira/browse/GEODE-8617
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.9.0, 1.11.0, 1.12.0
>Reporter: Donal Evans
>Priority: Major
>
> This failure shows up in RollingUpgrade and BackwardsCompatibility tests
> occasionally when attempting to bounce a VM and restart it with a different
> version of Geode. The initial failure shows up as an {{EOFException}}, but
> subsequent runs of the same test with other versions (as part of the
> RollingUpgrade/BackwardsCompatibility test) fail with {{ConnectException:
> Connection refused (Connection refused)}}.
> Two other tickets (GEODE-7142 and GEODE-6337) exist describing this failure
> in specific RollingUpgrade tests, but as it seems to be more general and not
> related to a specific test, this ticket has been created to consolidate them.
> An example failure from a BackwardsCompatibility test is attached below.
> {noformat}
> > Task :geode-core:upgradeTest
> org.apache.geode.internal.cache.TxCommitMessageBCOldClientToServerTxPartitionTest
> > test[9] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.VM$$Lambda$30/1525819532.run in VM 3 running on
> Host fad43bff7558 with 5 VMs with version 1.9.1
> Caused by:
> java.rmi.UnmarshalException: Error unmarshaling return header; nested
> exception is:
> java.io.EOFException
> Caused by:
> java.io.EOFException
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.TxCommitMessageBCTestBase$$Lambda$44/1148702340.run
> in VM 3 running on Host fad43bff7558 with 5 VMs with version 1.9.1
> Caused by:
> java.lang.IllegalStateException: VM not available: VM 3 running on
> Host fad43bff7558 with 5 VMs with version 1.9.1
> org.apache.geode.internal.cache.TxCommitMessageBCOldClientToServerTxPartitionTest
> > test[10] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.VM$$Lambda$29/478086753.call in VM 3 running on
> Host fad43bff7558 with 5 VMs with version 1.9.1
> Caused by:
> java.rmi.ConnectException: Connection refused to host: 172.17.0.49;
> nested exception is:
> java.net.ConnectException: Connection refused (Connection refused)
> Caused by:
> java.net.ConnectException: Connection refused (Connection refused)
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.TxCommitMessageBCTestBase$$Lambda$44/1148702340.run
> in VM 3 running on Host fad43bff7558 with 5 VMs with version 1.9.1
> Caused by:
> java.rmi.ConnectException: Connection refused to host: 172.17.0.49;
> nested exception is:
> java.net.ConnectException: Connection refused (Connection refused)
> Caused by:
> java.net.ConnectException: Connection refused (Connection refused)
> org.apache.geode.internal.cache.TxCommitMessageBCOldClientToServerTxPartitionTest
> > test[11] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.internal.IdentifiableRunnable.run in VM 3 running
> on Host fad43bff7558 with 5 VMs with version 1.9.1
> Caused by:
> java.rmi.ConnectException: Connection refused to host: 172.17.0.49;
> nested exception is:
> java.net.ConnectException: Connection refused (Connection refused)
> Caused by:
> java.net.ConnectException: Connection refused (Connection refused)
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.TxCommitMessageBCTestBase$$Lambda$44/1148702340.run
> in VM 3 running on Host fad43bff7558 with 5 VMs with version 1.9.1
> Caused by:
> java.rmi.ConnectException: Connection refused to host: 172.17.0.49;
> nested exception is:
> java.net.ConnectException: Connection refused (Connection refused)
> Caused by:
> java.net.ConnectException: Connection refused (Connection refused)
> org.apache.geode.internal.cache.TxCommitMessageBCOldClientToServerTxPartitionTest
> > test[12] FAILED
> org.apache.geode.test.dunit.RMIException:
[jira] [Created] (GEODE-8617) org.apache.geode.test.dunit.VM.bounce() fails to restart VM with different Geode version due to EOFException
Donal Evans created GEODE-8617:
--
Summary: org.apache.geode.test.dunit.VM.bounce() fails to restart
VM with different Geode version due to EOFException
Key: GEODE-8617
URL: https://issues.apache.org/jira/browse/GEODE-8617
Project: Geode
Issue Type: Bug
Affects Versions: 1.12.0, 1.11.0, 1.9.0
Reporter: Donal Evans
This failure shows up in RollingUpgrade and BackwardsCompatibility tests
occasionally when attempting to bounce a VM and restart it with a different
version of Geode. The initial failure shows up as an {{EOFException}}, but
subsequent runs of the same test with other versions (as part of the
RollingUpgrade/BackwardsCompatibility test) fail with {{ConnectException:
Connection refused (Connection refused)}}.
Two other tickets (GEODE-7142 and GEODE-6337) exist describing this failure in
specific RollingUpgrade tests, but as it seems to be more general and not
related to a specific test, this ticket has been created to consolidate them.
An example failure from a BackwardsCompatibility test is attached below.
{noformat}
> Task :geode-core:upgradeTest
org.apache.geode.internal.cache.TxCommitMessageBCOldClientToServerTxPartitionTest
> test[9] FAILED
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.test.dunit.VM$$Lambda$30/1525819532.run in VM 3 running on
Host fad43bff7558 with 5 VMs with version 1.9.1
Caused by:
java.rmi.UnmarshalException: Error unmarshaling return header; nested
exception is:
java.io.EOFException
Caused by:
java.io.EOFException
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.internal.cache.TxCommitMessageBCTestBase$$Lambda$44/1148702340.run
in VM 3 running on Host fad43bff7558 with 5 VMs with version 1.9.1
Caused by:
java.lang.IllegalStateException: VM not available: VM 3 running on Host
fad43bff7558 with 5 VMs with version 1.9.1
org.apache.geode.internal.cache.TxCommitMessageBCOldClientToServerTxPartitionTest
> test[10] FAILED
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.test.dunit.VM$$Lambda$29/478086753.call in VM 3 running on
Host fad43bff7558 with 5 VMs with version 1.9.1
Caused by:
java.rmi.ConnectException: Connection refused to host: 172.17.0.49;
nested exception is:
java.net.ConnectException: Connection refused (Connection refused)
Caused by:
java.net.ConnectException: Connection refused (Connection refused)
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.internal.cache.TxCommitMessageBCTestBase$$Lambda$44/1148702340.run
in VM 3 running on Host fad43bff7558 with 5 VMs with version 1.9.1
Caused by:
java.rmi.ConnectException: Connection refused to host: 172.17.0.49;
nested exception is:
java.net.ConnectException: Connection refused (Connection refused)
Caused by:
java.net.ConnectException: Connection refused (Connection refused)
org.apache.geode.internal.cache.TxCommitMessageBCOldClientToServerTxPartitionTest
> test[11] FAILED
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.test.dunit.internal.IdentifiableRunnable.run in VM 3 running
on Host fad43bff7558 with 5 VMs with version 1.9.1
Caused by:
java.rmi.ConnectException: Connection refused to host: 172.17.0.49;
nested exception is:
java.net.ConnectException: Connection refused (Connection refused)
Caused by:
java.net.ConnectException: Connection refused (Connection refused)
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.internal.cache.TxCommitMessageBCTestBase$$Lambda$44/1148702340.run
in VM 3 running on Host fad43bff7558 with 5 VMs with version 1.9.1
Caused by:
java.rmi.ConnectException: Connection refused to host: 172.17.0.49;
nested exception is:
java.net.ConnectException: Connection refused (Connection refused)
Caused by:
java.net.ConnectException: Connection refused (Connection refused)
org.apache.geode.internal.cache.TxCommitMessageBCOldClientToServerTxPartitionTest
> test[12] FAILED
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.test.dunit.internal.IdentifiableRunnable.run in VM 3 running
on Host fad43bff7558 with 5 VMs with version 1.9.1
Caused by:
java.rmi.ConnectException: Connection refused to host: 172.17.0.49;
nested exception is:
java.net.ConnectException: Connection refused (Connection refused)
Caused by:
java.net.ConnectException: Connection refused (Connection refused)
org.apache.geode.test.dunit.RMIException: While invoking
[jira] [Commented] (GEODE-8584) Message transmission fails with IllegalStateException in socket i/o code
[
https://issues.apache.org/jira/browse/GEODE-8584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17214916#comment-17214916
]
ASF GitHub Bot commented on GEODE-8584:
---
Bill opened a new pull request #5631:
URL: https://github.com/apache/geode/pull/5631
The initial fix for
[GEODE-8584](https://issues.apache.org/jira/browse/GEODE-8584) has a hang when
`Connection.notifyHandshakeWaiter()` tries to acquire the monitor on the
`ByteBuffer` but that monitor is already held by another thread that is trying
to read an ack.
The fix here is to simply not try to acquire the monitor if we are closing
the connection.
- [x] Is there a JIRA ticket associated with this PR? Is it referenced in
the commit message?
- [x] Has your PR been rebased against the latest commit within the target
branch (typically `develop`)?
- [x] Is your initial contribution a single, squashed commit?
- [x] Does `gradlew build` run cleanly?
- [ ] Have you written or updated unit tests to verify your changes?
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Message transmission fails with IllegalStateException in socket i/o code
>
>
> Key: GEODE-8584
> URL: https://issues.apache.org/jira/browse/GEODE-8584
> Project: Geode
> Issue Type: Bug
> Components: membership, messaging
>Affects Versions: 1.12.0, 1.13.0, 1.14.0
>Reporter: Bruce J Schuchardt
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.12.1, 1.14.0, 1.13.1
>
>
> Transmission of an update operation failed with a toData exception caused by
> an IllegalStateException in socket i/o code. It shouldn't be possible for
> this exception to happen unless multiple threads are using the buffer at the
> same time.
>
> {noformat}
> org.apache.geode.ToDataException: toData failed on dsfid=71 msg:null
> at
> org.apache.geode.internal.InternalDataSerializer.writeDSFID(InternalDataSerializer.java:1509)
> at
> org.apache.geode.internal.tcp.MsgStreamer.writeMessage(MsgStreamer.java:249)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:306)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:182)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:511)
> at
> org.apache.geode.distributed.internal.DistributionImpl.directChannelSend(DistributionImpl.java:346)
> at
> org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:291)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2053)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:1981)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendMessage(ClusterDistributionManager.java:2018)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.putOutgoing(ClusterDistributionManager.java:1083)
> at
> org.apache.geode.internal.cache.DistributedCacheOperation._distribute(DistributedCacheOperation.java:572)
> at
> org.apache.geode.internal.cache.DistributedCacheOperation.startOperation(DistributedCacheOperation.java:277)
> at
> org.apache.geode.internal.cache.DistributedCacheOperation.distribute(DistributedCacheOperation.java:318)
> at
> org.apache.geode.internal.cache.DistributedRegion.distributeUpdate(DistributedRegion.java:520)
> at
> org.apache.geode.internal.cache.DistributedRegion.basicPutPart3(DistributedRegion.java:498)
> at
> org.apache.geode.internal.cache.map.RegionMapPut.doAfterCompletionActions(RegionMapPut.java:307)
> at
> org.apache.geode.internal.cache.map.AbstractRegionMapPut.doPut(AbstractRegionMapPut.java:185)
> at
> org.apache.geode.internal.cache.map.AbstractRegionMapPut.runWhileLockedForCacheModification(AbstractRegionMapPut.java:119)
> at
> org.apache.geode.internal.cache.map.RegionMapPut.runWhileLockedForCacheModification(RegionMapPut.java:161)
> at
> org.apache.geode.internal.cache.map.AbstractRegionMapPut.put(AbstractRegionMapPut.java:169)
> at
> org.apache.geode.internal.cache.AbstractRegionMap.basicPut(AbstractRegionMap.java:2044)
> at
> org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5599)
> at
>
[jira] [Updated] (GEODE-8616) ClientServerCacheOperationDUnitTest > largeObjectPutWithReadTimeoutThrowsException fails with "Pool unexpected socket timed out on client"
[
https://issues.apache.org/jira/browse/GEODE-8616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans updated GEODE-8616:
---
Description:
{noformat}
> Task :geode-core:distributedTest
org.apache.geode.cache30.ClientServerCacheOperationDUnitTest >
largeObjectPutWithReadTimeoutThrowsException FAILED
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.cache30.ClientServerCacheOperationDUnitTest$$Lambda$177/0x000100b52040.run
in VM 2 running on Host c1346ab7b3e3 with 4 VMs
at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610)
at org.apache.geode.test.dunit.VM.invoke(VM.java:437)
at
org.apache.geode.cache30.ClientServerCacheOperationDUnitTest.largeObjectPutWithReadTimeoutThrowsException(ClientServerCacheOperationDUnitTest.java:117)
Caused by:
org.apache.geode.cache.client.ServerConnectivityException: Pool
unexpected socket timed out on client connection=Pooled Connection to
c1346ab7b3e3:35437: Connection[DESTROYED]). Server unreachable: could not
connect after 1 attempts
at
org.apache.geode.cache.client.internal.OpExecutorImpl.handleException(OpExecutorImpl.java:659)
at
org.apache.geode.cache.client.internal.OpExecutorImpl.handleException(OpExecutorImpl.java:501)
at
org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:153)
at
org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:108)
at
org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:774)
at
org.apache.geode.cache.client.internal.GetOp.execute(GetOp.java:91)
at
org.apache.geode.cache.client.internal.ServerRegionProxy.get(ServerRegionProxy.java:116)
at
org.apache.geode.internal.cache.LocalRegion.findObjectInSystem(LocalRegion.java:2795)
at
org.apache.geode.internal.cache.LocalRegion.getObject(LocalRegion.java:1472)
at
org.apache.geode.internal.cache.LocalRegion.nonTxnFindObject(LocalRegion.java:1445)
at
org.apache.geode.internal.cache.LocalRegionDataView.findObject(LocalRegionDataView.java:196)
at
org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1382)
at
org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1321)
at
org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1306)
at
org.apache.geode.internal.cache.AbstractRegion.get(AbstractRegion.java:436)
at
org.apache.geode.cache30.ClientServerCacheOperationDUnitTest.lambda$largeObjectPutWithReadTimeoutThrowsException$3ab01cf6$2(ClientServerCacheOperationDUnitTest.java:120)
{noformat}
=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
http://files.apachegeode-ci.info/builds/apache-support-1-12-main/1.12.1-build.0106/test-results/distributedTest/1601514101/
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Test report artifacts from this job are available at:
http://files.apachegeode-ci.info/builds/apache-support-1-12-main/1.12.1-build.0106/test-artifacts/1601514101/distributedtestfiles-OpenJDK11-1.12.1-build.0106.tgz
This is a flaky failure.
was:
{noformat}
> Task :geode-core:distributedTest
org.apache.geode.cache30.ClientServerCacheOperationDUnitTest >
largeObjectPutWithReadTimeoutThrowsException FAILED
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.cache30.ClientServerCacheOperationDUnitTest$$Lambda$177/0x000100b52040.run
in VM 2 running on Host c1346ab7b3e3 with 4 VMs
at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610)
at org.apache.geode.test.dunit.VM.invoke(VM.java:437)
at
org.apache.geode.cache30.ClientServerCacheOperationDUnitTest.largeObjectPutWithReadTimeoutThrowsException(ClientServerCacheOperationDUnitTest.java:117)
Caused by:
org.apache.geode.cache.client.ServerConnectivityException: Pool
unexpected socket timed out on client connection=Pooled Connection to
c1346ab7b3e3:35437: Connection[DESTROYED]). Server unreachable: could not
connect after 1 attempts
at
org.apache.geode.cache.client.internal.OpExecutorImpl.handleException(OpExecutorImpl.java:659)
at
org.apache.geode.cache.client.internal.OpExecutorImpl.handleException(OpExecutorImpl.java:501)
at
org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:153)
at
org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:108)
at
org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:774)
at
org.apache.geode.cache.client.internal.GetOp.execute(GetOp.java:91)
at
org.apache.geode.cache.client.internal.ServerRegionProxy.get(ServerRegionProxy.java:116)
[jira] [Commented] (GEODE-8609) Create a dunit suspect file per VM
[
https://issues.apache.org/jira/browse/GEODE-8609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17214864#comment-17214864
]
ASF GitHub Bot commented on GEODE-8609:
---
jdeppe-pivotal commented on a change in pull request #5625:
URL: https://github.com/apache/geode/pull/5625#discussion_r505719069
##
File path:
geode-dunit/src/main/java/org/apache/geode/test/dunit/internal/DUnitLauncher.java
##
@@ -395,12 +395,18 @@ public static void closeAndCheckForSuspects() {
+ "' - perhaps a rule that is cleaning up before suspect processing
has already run.");
}
+boolean ok = true;
Review comment:
Good idea - I'll apply that shortly.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Create a dunit suspect file per VM
> --
>
> Key: GEODE-8609
> URL: https://issues.apache.org/jira/browse/GEODE-8609
> Project: Geode
> Issue Type: Test
> Components: tests
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
> Labels: pull-request-available
>
> In some situations, especially when restarting Dunit VMs, it appears that the
> suspect log file can be corrupted since suspect processing reports errors
> such as:
> {noformat}
> org.apache.geode.redis.internal.executor.CrashAndNoRepeatDUnitTest >
> classMethod FAILED
> java.lang.AssertionError: Suspicious strings were written to the log
> during this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in log4j at line 19594
> /home/geode/.gradle/caches/modules-2/files-2.1/antlr/antlr/2.7.7/83cd2cd674a21[warn
> 2020/10/11 15:23:24.988 GMT tid=105] Execution
> of Redis command APPEND append-key-1 -append-key-1-17484- failed:
> org.apache.geode.cache.execute.FunctionException:
> org.apache.geode.cache.execute.FunctionInvocationTargetException:
> memberDeparted event for < 172.17.0.20(server-3:2004):41003 > crashed,
> true{noformat}
> Where the suspected string is corrupted.
> The proposed fix will create a new dunit_suspect log for each VM. The logs
> will now be named {{dunit_suspect-vm.log}}. The {{locator}} vm and the
> test runner vm will have logs named {{dunit_suspect-locator.log}} and
> {{dunit_suspect-local.log}} respectively.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8609) Create a dunit suspect file per VM
[
https://issues.apache.org/jira/browse/GEODE-8609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17214862#comment-17214862
]
ASF GitHub Bot commented on GEODE-8609:
---
jdeppe-pivotal commented on a change in pull request #5625:
URL: https://github.com/apache/geode/pull/5625#discussion_r505718687
##
File path:
geode-dunit/src/main/java/org/apache/geode/test/dunit/internal/DUnitLauncher.java
##
@@ -343,59 +339,120 @@ public static void init(MasterRemote master) {
System.setProperty(LAUNCHED_PROPERTY, "true");
}
+ private static List getDunitSuspectFiles() {
+File[] suspectFiles = getDunitSuspectsDir()
+.listFiles((dir, name) -> name.startsWith(SUSPECT_FILENAME_PREFIX));
+
+return Arrays.asList(suspectFiles);
+ }
+
+ private static File getDunitSuspectsDir() {
+return Paths.get(getWorkspaceDir()).toFile();
+ }
+
+ private static void deleteDunitSuspectFiles() {
+getDunitSuspectFiles().forEach(File::delete);
+ }
+
+ private static File createDunitSuspectFile(int vmId, String workingDir) {
+String suffix;
+
+switch (vmId) {
+ case -2:
+suffix = "locator";
+break;
+ case -1:
+suffix = "local";
+break;
+ default:
+suffix = "vm" + vmId;
+}
+
+File dunitSuspect = new File(getDunitSuspectsDir(),
+String.format("%s-%s.log", SUSPECT_FILENAME_PREFIX, suffix));
+dunitSuspect.deleteOnExit();
+
+return dunitSuspect;
+ }
+
+ private static String getWorkspaceDir() {
+String workspaceDir =
System.getProperty(DUnitLauncher.WORKSPACE_DIR_PARAM);
+workspaceDir = workspaceDir == null ? new File(".").getAbsolutePath() :
workspaceDir;
+
+return workspaceDir;
+ }
+
public static void closeAndCheckForSuspects() {
-if (isLaunched()) {
- final List expectedStrings = ExpectedStrings.create("dunit");
- final LogConsumer logConsumer = new LogConsumer(true, expectedStrings,
"log4j", 5);
+if (!isLaunched()) {
+ return;
+}
- final StringBuilder suspectStringBuilder = new StringBuilder();
+List suspectFiles = getDunitSuspectFiles();
- BufferedReader buffReader = null;
- FileChannel fileChannel = null;
- try {
-fileChannel = new FileOutputStream(DUNIT_SUSPECT_FILE,
true).getChannel();
-buffReader = new BufferedReader(new FileReader(DUNIT_SUSPECT_FILE));
- } catch (FileNotFoundException e) {
-System.err.println("Could not find the suspect string output file: " +
e);
-return;
- }
+if (suspectFiles.isEmpty()) {
+ throw new IllegalStateException("No dunit suspect log files found in '"
+ + getDunitSuspectsDir().getAbsolutePath()
+ + "' - perhaps a rule that is cleaning up before suspect processing
has already run.");
+}
+
+for (File suspect : suspectFiles) {
+ checkSuspectFile(suspect);
+}
+ }
+
+ public static void checkSuspectFile(File suspectFile) {
+final List expectedStrings = ExpectedStrings.create("dunit");
+final LogConsumer logConsumer = new LogConsumer(true, expectedStrings,
+suspectFile.getName(), 5);
+
+final StringBuilder suspectStringBuilder = new StringBuilder();
+
+BufferedReader buffReader;
+FileChannel fileChannel;
+try {
+ fileChannel = new FileOutputStream(suspectFile, true).getChannel();
+ buffReader = new BufferedReader(new FileReader(suspectFile));
+} catch (FileNotFoundException e) {
+ System.err.println("Could not find the suspect string output file: " +
e);
+ return;
+}
+
+try {
+ String line;
try {
-String line;
-try {
- while ((line = buffReader.readLine()) != null) {
-final StringBuilder builder = logConsumer.consume(line);
-if (builder != null) {
- suspectStringBuilder.append(builder);
-}
+while ((line = buffReader.readLine()) != null) {
+ final StringBuilder builder = logConsumer.consume(line);
+ if (builder != null) {
+suspectStringBuilder.append(builder);
}
-} catch (IOException e) {
- System.err.println("Could not read the suspect string output file: "
+ e);
}
+ } catch (IOException e) {
+System.err.println("Could not read the suspect string output file: " +
e);
+ }
-try {
- fileChannel.truncate(0);
-} catch (IOException e) {
- System.err.println("Could not truncate the suspect string output
file: " + e);
-}
+ try {
+fileChannel.truncate(0);
+ } catch (IOException e) {
+System.err.println("Could not truncate the suspect string output file:
" + e);
+ }
- } finally {
-try {
- buffReader.close();
- fileChannel.close();
-} catch (IOException e) {
-
[jira] [Commented] (GEODE-8616) ClientServerCacheOperationDUnitTest > largeObjectPutWithReadTimeoutThrowsException fails with "Pool unexpected socket timed out on client"
[
https://issues.apache.org/jira/browse/GEODE-8616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17214861#comment-17214861
]
Geode Integration commented on GEODE-8616:
--
Seen in [DistributedTestOpenJDK11
#83|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-12-main/jobs/DistributedTestOpenJDK11/builds/83].
> ClientServerCacheOperationDUnitTest >
> largeObjectPutWithReadTimeoutThrowsException fails with "Pool unexpected
> socket timed out on client"
> --
>
> Key: GEODE-8616
> URL: https://issues.apache.org/jira/browse/GEODE-8616
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.12.1
>Reporter: Donal Evans
>Priority: Major
>
> {noformat}
> > Task :geode-core:distributedTest
> org.apache.geode.cache30.ClientServerCacheOperationDUnitTest >
> largeObjectPutWithReadTimeoutThrowsException FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.cache30.ClientServerCacheOperationDUnitTest$$Lambda$177/0x000100b52040.run
> in VM 2 running on Host c1346ab7b3e3 with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:437)
> at
> org.apache.geode.cache30.ClientServerCacheOperationDUnitTest.largeObjectPutWithReadTimeoutThrowsException(ClientServerCacheOperationDUnitTest.java:117)
> Caused by:
> org.apache.geode.cache.client.ServerConnectivityException: Pool
> unexpected socket timed out on client connection=Pooled Connection to
> c1346ab7b3e3:35437: Connection[DESTROYED]). Server unreachable: could not
> connect after 1 attempts
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.handleException(OpExecutorImpl.java:659)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.handleException(OpExecutorImpl.java:501)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:153)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:108)
> at
> org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:774)
> at
> org.apache.geode.cache.client.internal.GetOp.execute(GetOp.java:91)
> at
> org.apache.geode.cache.client.internal.ServerRegionProxy.get(ServerRegionProxy.java:116)
> at
> org.apache.geode.internal.cache.LocalRegion.findObjectInSystem(LocalRegion.java:2795)
> at
> org.apache.geode.internal.cache.LocalRegion.getObject(LocalRegion.java:1472)
> at
> org.apache.geode.internal.cache.LocalRegion.nonTxnFindObject(LocalRegion.java:1445)
> at
> org.apache.geode.internal.cache.LocalRegionDataView.findObject(LocalRegionDataView.java:196)
> at
> org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1382)
> at
> org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1321)
> at
> org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1306)
> at
> org.apache.geode.internal.cache.AbstractRegion.get(AbstractRegion.java:436)
> at
> org.apache.geode.cache30.ClientServerCacheOperationDUnitTest.lambda$largeObjectPutWithReadTimeoutThrowsException$3ab01cf6$2(ClientServerCacheOperationDUnitTest.java:120)
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-support-1-12-main/1.12.1-build.0106/test-results/distributedTest/1601514101/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> This is a flaky failure.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-8616) ClientServerCacheOperationDUnitTest > largeObjectPutWithReadTimeoutThrowsException fails with "Pool unexpected socket timed out on client"
Donal Evans created GEODE-8616:
--
Summary: ClientServerCacheOperationDUnitTest >
largeObjectPutWithReadTimeoutThrowsException fails with "Pool unexpected socket
timed out on client"
Key: GEODE-8616
URL: https://issues.apache.org/jira/browse/GEODE-8616
Project: Geode
Issue Type: Bug
Affects Versions: 1.12.1
Reporter: Donal Evans
{noformat}
> Task :geode-core:distributedTest
org.apache.geode.cache30.ClientServerCacheOperationDUnitTest >
largeObjectPutWithReadTimeoutThrowsException FAILED
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.cache30.ClientServerCacheOperationDUnitTest$$Lambda$177/0x000100b52040.run
in VM 2 running on Host c1346ab7b3e3 with 4 VMs
at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610)
at org.apache.geode.test.dunit.VM.invoke(VM.java:437)
at
org.apache.geode.cache30.ClientServerCacheOperationDUnitTest.largeObjectPutWithReadTimeoutThrowsException(ClientServerCacheOperationDUnitTest.java:117)
Caused by:
org.apache.geode.cache.client.ServerConnectivityException: Pool
unexpected socket timed out on client connection=Pooled Connection to
c1346ab7b3e3:35437: Connection[DESTROYED]). Server unreachable: could not
connect after 1 attempts
at
org.apache.geode.cache.client.internal.OpExecutorImpl.handleException(OpExecutorImpl.java:659)
at
org.apache.geode.cache.client.internal.OpExecutorImpl.handleException(OpExecutorImpl.java:501)
at
org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:153)
at
org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:108)
at
org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:774)
at
org.apache.geode.cache.client.internal.GetOp.execute(GetOp.java:91)
at
org.apache.geode.cache.client.internal.ServerRegionProxy.get(ServerRegionProxy.java:116)
at
org.apache.geode.internal.cache.LocalRegion.findObjectInSystem(LocalRegion.java:2795)
at
org.apache.geode.internal.cache.LocalRegion.getObject(LocalRegion.java:1472)
at
org.apache.geode.internal.cache.LocalRegion.nonTxnFindObject(LocalRegion.java:1445)
at
org.apache.geode.internal.cache.LocalRegionDataView.findObject(LocalRegionDataView.java:196)
at
org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1382)
at
org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1321)
at
org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1306)
at
org.apache.geode.internal.cache.AbstractRegion.get(AbstractRegion.java:436)
at
org.apache.geode.cache30.ClientServerCacheOperationDUnitTest.lambda$largeObjectPutWithReadTimeoutThrowsException$3ab01cf6$2(ClientServerCacheOperationDUnitTest.java:120)
{noformat}
=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
http://files.apachegeode-ci.info/builds/apache-support-1-12-main/1.12.1-build.0106/test-results/distributedTest/1601514101/
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
This is a flaky failure.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8157) Write "drop proxy test" for C# (clicache)
[
https://issues.apache.org/jira/browse/GEODE-8157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17214830#comment-17214830
]
ASF GitHub Bot commented on GEODE-8157:
---
echobravopapa commented on a change in pull request #674:
URL: https://github.com/apache/geode-native/pull/674#discussion_r505687688
##
File path: clicache/acceptance-test/SNITests.cs
##
@@ -127,5 +133,38 @@ public void ConnectionWithoutProxyFails()
Assert.Throws(() => region.Put("1", "one"));
}
+
Review comment:
It would be great to have this test:
- bring up the system/cluster
- do a cache ops (put/get)
- drop the proxy
- attempt cache ops - wait for exception (EXPECTEXCEPTION in gtest or
similar...)
- bring proxy back up
- then do verify cache ops (put/get)
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Write "drop proxy test" for C# (clicache)
> -
>
> Key: GEODE-8157
> URL: https://issues.apache.org/jira/browse/GEODE-8157
> Project: Geode
> Issue Type: New Feature
> Components: native client
>Reporter: Blake Bender
>Priority: Major
> Labels: pull-request-available
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7982) Suspect string from RollingUpgradeQueryReturnsCorrectResultsAfterClientAndServersAreRolledOverAllBucketsCreated
[
https://issues.apache.org/jira/browse/GEODE-7982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17214827#comment-17214827
]
Geode Integration commented on GEODE-7982:
--
Seen in [UpgradeTestOpenJDK11
#76|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-12-main/jobs/UpgradeTestOpenJDK11/builds/76].
> Suspect string from
> RollingUpgradeQueryReturnsCorrectResultsAfterClientAndServersAreRolledOverAllBucketsCreated
> ---
>
> Key: GEODE-7982
> URL: https://issues.apache.org/jira/browse/GEODE-7982
> Project: Geode
> Issue Type: Bug
> Components: querying
>Reporter: Dan Smith
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> This upgrade test failed with a suspect string from a background thread:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/UpgradeTestOpenJDK8/builds/49#A
> {noformat}
> org.apache.geode.cache.lucene.RollingUpgradeQueryReturnsCorrectResultsAfterClientAndServersAreRolledOverAllBucketsCreated
> > test[from_v1.9.1, with reindex=false, singleHopEnabled=true] FAILED
> java.lang.AssertionError: Suspicious strings were written to the log
> during this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in log4j at line 8954
> /home/geode/.gradle/caches/modules-2/file[info 2020/04/13 18:04:58.681
> GMT tid=81] Communication with locator
> /172.17.0.40:23082 failed with java.io.EOFException: Locator at
> /172.17.0.40:23082 did not respond. This is normal if the locator was
> shutdown. If it wasn't check its log for exceptions..
> java.io.EOFException: Locator at /172.17.0.40:23082 did not respond. This
> is normal if the locator was shutdown. If it wasn't check its log for
> exceptions.
> at
> org.apache.geode.distributed.internal.tcpserver.TcpClient.requestToServer(TcpClient.java:232)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryOneLocatorUsingConnection(AutoConnectionSourceImpl.java:209)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryOneLocator(AutoConnectionSourceImpl.java:199)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryLocators(AutoConnectionSourceImpl.java:287)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl$UpdateLocatorListTask.run2(AutoConnectionSourceImpl.java:500)
> at
> org.apache.geode.cache.client.internal.PoolImpl$PoolTask.run(PoolImpl.java:1371)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> at
> org.apache.geode.internal.ScheduledThreadPoolExecutorWithKeepAlive$DelegatingScheduledFuture.run(ScheduledThreadPoolExecutorWithKeepAlive.java:276)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.io.EOFException
> at java.io.DataInputStream.readByte(DataInputStream.java:267)
> at
> org.apache.geode.internal.InternalDataSerializer.basicReadObject(InternalDataSerializer.java:2775)
> at org.apache.geode.DataSerializer.readObject(DataSerializer.java:2978)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpClient.requestToServer(TcpClient.java:227)
> ... 11 more
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8595) RandomRule to provide GsRandom utilities for dunit tests
[
https://issues.apache.org/jira/browse/GEODE-8595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17214821#comment-17214821
]
ASF GitHub Bot commented on GEODE-8595:
---
demery-pivotal commented on a change in pull request #5612:
URL: https://github.com/apache/geode/pull/5612#discussion_r505675165
##
File path:
geode-junit/src/main/java/org/apache/geode/test/junit/rules/RandomRule.java
##
@@ -0,0 +1,271 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
contributor license
+ * agreements. See the NOTICE file distributed with this work for additional
information regarding
+ * copyright ownership. The ASF licenses this file to You under the Apache
License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the
License. You may obtain a
+ * copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
distributed under the License
+ * is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express
+ * or implied. See the License for the specific language governing permissions
and limitations under
+ * the License.
+ */
+package org.apache.geode.test.junit.rules;
+
+import static java.util.Arrays.asList;
+import static java.util.Objects.requireNonNull;
+import static java.util.stream.Collectors.toList;
+import static java.util.stream.StreamSupport.stream;
+
+import java.util.List;
+import java.util.Random;
+import java.util.concurrent.atomic.AtomicReference;
+
+import org.junit.runner.Description;
+import org.junit.runners.model.Statement;
+
+import org.apache.geode.test.junit.rules.serializable.SerializableStatement;
+import org.apache.geode.test.junit.rules.serializable.SerializableTestRule;
+
+@SuppressWarnings({"serial", "unused", "WeakerAccess",
"NumericCastThatLosesPrecision"})
+public class RandomRule extends Random implements GsRandom,
SerializableTestRule {
+
+ private final AtomicReference random = new AtomicReference<>();
+ private final long seed;
+
Review comment:
Would it be useful to have an additional constructor that takes a
`Random`, or a `Supplier`?
##
File path:
geode-junit/src/main/java/org/apache/geode/test/junit/rules/RandomRule.java
##
@@ -0,0 +1,271 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
contributor license
+ * agreements. See the NOTICE file distributed with this work for additional
information regarding
+ * copyright ownership. The ASF licenses this file to You under the Apache
License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the
License. You may obtain a
+ * copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
distributed under the License
+ * is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express
+ * or implied. See the License for the specific language governing permissions
and limitations under
+ * the License.
+ */
+package org.apache.geode.test.junit.rules;
+
+import static java.util.Arrays.asList;
+import static java.util.Objects.requireNonNull;
+import static java.util.stream.Collectors.toList;
+import static java.util.stream.StreamSupport.stream;
+
+import java.util.List;
+import java.util.Random;
+import java.util.concurrent.atomic.AtomicReference;
+
+import org.junit.runner.Description;
+import org.junit.runners.model.Statement;
+
+import org.apache.geode.test.junit.rules.serializable.SerializableStatement;
+import org.apache.geode.test.junit.rules.serializable.SerializableTestRule;
+
+@SuppressWarnings({"serial", "unused", "WeakerAccess",
"NumericCastThatLosesPrecision"})
+public class RandomRule extends Random implements GsRandom,
SerializableTestRule {
+
+ private final AtomicReference random = new AtomicReference<>();
+ private final long seed;
+
+ public RandomRule() {
+this(0);
+ }
+
+ public RandomRule(long seed) {
+this.seed = seed;
+ }
+
+ @Override
+ public Statement apply(final Statement base, final Description description) {
+return statement(base);
+ }
+
+ private Statement statement(final Statement base) {
+return new SerializableStatement() {
+ @Override
+ public void evaluate() throws Throwable {
+before();
+try {
+ base.evaluate();
+} finally {
+ // nothing
+}
+ }
+};
+ }
+
+ private void before() {
+random.set(newRandom());
+ }
+
+ /**
+ * Returns the next pseudorandom, uniformly distributed {@code boolean}
value from this random
+ * number generator's sequence.
+ *
+ * @return the next pseudorandom, uniformly distributed {@code boolean}
value from this random
+ * number generator's sequence.
+ */
+
[jira] [Commented] (GEODE-8609) Create a dunit suspect file per VM
[
https://issues.apache.org/jira/browse/GEODE-8609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17214810#comment-17214810
]
ASF GitHub Bot commented on GEODE-8609:
---
demery-pivotal commented on a change in pull request #5625:
URL: https://github.com/apache/geode/pull/5625#discussion_r505669152
##
File path:
geode-dunit/src/main/java/org/apache/geode/test/dunit/internal/DUnitLauncher.java
##
@@ -395,12 +395,18 @@ public static void closeAndCheckForSuspects() {
+ "' - perhaps a rule that is cleaning up before suspect processing
has already run.");
}
+boolean ok = true;
Review comment:
An alternative is to create a `StringBuilder` here and pass it into
`checkSuspectFile()` to collect the suspects. That way the strings can be
included in the assertion failure message.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Create a dunit suspect file per VM
> --
>
> Key: GEODE-8609
> URL: https://issues.apache.org/jira/browse/GEODE-8609
> Project: Geode
> Issue Type: Test
> Components: tests
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
> Labels: pull-request-available
>
> In some situations, especially when restarting Dunit VMs, it appears that the
> suspect log file can be corrupted since suspect processing reports errors
> such as:
> {noformat}
> org.apache.geode.redis.internal.executor.CrashAndNoRepeatDUnitTest >
> classMethod FAILED
> java.lang.AssertionError: Suspicious strings were written to the log
> during this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in log4j at line 19594
> /home/geode/.gradle/caches/modules-2/files-2.1/antlr/antlr/2.7.7/83cd2cd674a21[warn
> 2020/10/11 15:23:24.988 GMT tid=105] Execution
> of Redis command APPEND append-key-1 -append-key-1-17484- failed:
> org.apache.geode.cache.execute.FunctionException:
> org.apache.geode.cache.execute.FunctionInvocationTargetException:
> memberDeparted event for < 172.17.0.20(server-3:2004):41003 > crashed,
> true{noformat}
> Where the suspected string is corrupted.
> The proposed fix will create a new dunit_suspect log for each VM. The logs
> will now be named {{dunit_suspect-vm.log}}. The {{locator}} vm and the
> test runner vm will have logs named {{dunit_suspect-locator.log}} and
> {{dunit_suspect-local.log}} respectively.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8293) activeCQCount has negative value
[
https://issues.apache.org/jira/browse/GEODE-8293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17214807#comment-17214807
]
ASF GitHub Bot commented on GEODE-8293:
---
karensmolermiller commented on a change in pull request #5620:
URL: https://github.com/apache/geode/pull/5620#discussion_r505665589
##
File path: geode-docs/reference/statistics_list.html.md.erb
##
@@ -553,7 +553,12 @@ These statistics are in a client and they describe one of
the client’s connect
## Continuous Querying (CqQueryStats)
-These statistics are for continuous querying information. The statistics are:
+These statistics are for continuous querying information.
+
+**Note:**
+The subscription redundancy changes CQS_ACTIVE, CQS_STOPPED and CQS_CLOSED
count on partitioned region
Review comment:
Ok. Then, the prose belongs in the description next to each of these 3
statistics. And, that prose ought to say what the effect is (and not just that
the sub. red. level affects the values of the counters). If you'd like to talk
directly about wording, let me know and we'll find a way.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> activeCQCount has negative value
>
>
> Key: GEODE-8293
> URL: https://issues.apache.org/jira/browse/GEODE-8293
> Project: Geode
> Issue Type: Bug
> Components: statistics
>Reporter: Mario Kevo
>Assignee: Mario Kevo
>Priority: Major
> Labels: pull-request-available
>
> In case you have more than one server in the system and you close CQ there
> will be negative value of active cqs.
> The problem is when you started more than one server and execute cq on it. In
> that case we got incCqsActive on one server, but when it is closed we have
> decCqsActive on both servers.
> {code:java}
> gfsh>show metrics --categories=query
> Cluster-wide MetricsCategory | Metric | Value
> | | -
> query| activeCQCount| 1
> | queryRequestRate | 0.0
> {code}
> After cq is closed or stopped:
> {code:java}
> gfsh>show metrics --categories=query
> Cluster-wide Metrics
> Category | Metric | Value
> | | -
> query| activeCQCount| -1
> | queryRequestRate | 0.0
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8605) Alter some GW senders attributes in runtime
[
https://issues.apache.org/jira/browse/GEODE-8605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17214797#comment-17214797
]
Mario Ivanac commented on GEODE-8605:
-
Hi,
we are introducing new command `alter gateway-sender` which can be applied to
parallel or serial gateway sender with defined "id".
Checks on number of dispatcher threads and serial gateway sender, are specific
only for activation of "{color:#6a8759}group-transaction-events{color}"
parameter.
> Alter some GW senders attributes in runtime
> ---
>
> Key: GEODE-8605
> URL: https://issues.apache.org/jira/browse/GEODE-8605
> Project: Geode
> Issue Type: New Feature
> Components: docs, gfsh, wan
>Reporter: Mario Ivanac
>Assignee: Mario Ivanac
>Priority: Major
> Labels: pull-request-available
>
> We would like to introduce new command "alter gateway-sender" which would
> update some parameters in runtime. For now parameters of interest are:
> * {color:#6a8759}alert-threshold{color}
> * {color:#6a8759}batch-size{color}
> * {color:#6a8759}batch-time-interval{color}
> * {color:#6a8759}group-transaction-events{color}
> * {color:#6a8759}gateway-event-filter{color}
> * {color:#6a8759}gateway-transport-filter{color}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8605) Alter some GW senders attributes in runtime
[
https://issues.apache.org/jira/browse/GEODE-8605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Ivanac updated GEODE-8605:
Description:
We would like to introduce new command "alter gateway-sender" which would
update some parameters in runtime. For now parameters of interest are:
* {color:#6a8759}alert-threshold{color}
* {color:#6a8759}batch-size{color}
* {color:#6a8759}batch-time-interval{color}
* {color:#6a8759}group-transaction-events{color}
* {color:#6a8759}gateway-event-filter{color}
* {color:#6a8759}gateway-transport-filter{color}
was:
We would like to introduce new command "alter gateway-sender" which would
update some parameters in runtime. For now parameters of interest are:
* {color:#6a8759}alert-threshold{color}
* {color:#6a8759}batch-size{color}
* {color:#6a8759}batch-time-interval{color}
* {color:#6a8759}...{color}
> Alter some GW senders attributes in runtime
> ---
>
> Key: GEODE-8605
> URL: https://issues.apache.org/jira/browse/GEODE-8605
> Project: Geode
> Issue Type: New Feature
> Components: docs, gfsh, wan
>Reporter: Mario Ivanac
>Assignee: Mario Ivanac
>Priority: Major
> Labels: pull-request-available
>
> We would like to introduce new command "alter gateway-sender" which would
> update some parameters in runtime. For now parameters of interest are:
> * {color:#6a8759}alert-threshold{color}
> * {color:#6a8759}batch-size{color}
> * {color:#6a8759}batch-time-interval{color}
> * {color:#6a8759}group-transaction-events{color}
> * {color:#6a8759}gateway-event-filter{color}
> * {color:#6a8759}gateway-transport-filter{color}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8605) Alter some GW senders attributes in runtime
[
https://issues.apache.org/jira/browse/GEODE-8605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dave Barnes updated GEODE-8605:
---
Component/s: docs
> Alter some GW senders attributes in runtime
> ---
>
> Key: GEODE-8605
> URL: https://issues.apache.org/jira/browse/GEODE-8605
> Project: Geode
> Issue Type: New Feature
> Components: docs, gfsh, wan
>Reporter: Mario Ivanac
>Assignee: Mario Ivanac
>Priority: Major
> Labels: pull-request-available
>
> We would like to introduce new command "alter gateway-sender" which would
> update some parameters in runtime. For now parameters of interest are:
> * {color:#6a8759}alert-threshold{color}
> * {color:#6a8759}batch-size{color}
> * {color:#6a8759}batch-time-interval{color}
> * {color:#6a8759}...{color}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8605) Alter some GW senders attributes in runtime
[
https://issues.apache.org/jira/browse/GEODE-8605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17214781#comment-17214781
]
Dave Barnes commented on GEODE-8605:
Mario, when your PR becomes available for review, please add me as a reviewer.
I have a few suggestions to smooth out the language in the javadocs. I've also
added docs as a component on this ticket, as it will require an addition to the
user guide.
There's also one concept I'd like to better understand: "Only allowed on serial
gateway senders with 1 dispatcher thread or on parallel ones." Do I understand
correctly that you're adding a gfsh command, `alter gateway-sender`? And this
command can be applied to (any) parallel gateway senders or to a serial gateway
sender, (only) if it has only one dispatcher thread?
> Alter some GW senders attributes in runtime
> ---
>
> Key: GEODE-8605
> URL: https://issues.apache.org/jira/browse/GEODE-8605
> Project: Geode
> Issue Type: New Feature
> Components: docs, gfsh, wan
>Reporter: Mario Ivanac
>Assignee: Mario Ivanac
>Priority: Major
> Labels: pull-request-available
>
> We would like to introduce new command "alter gateway-sender" which would
> update some parameters in runtime. For now parameters of interest are:
> * {color:#6a8759}alert-threshold{color}
> * {color:#6a8759}batch-size{color}
> * {color:#6a8759}batch-time-interval{color}
> * {color:#6a8759}...{color}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8605) Alter some GW senders attributes in runtime
[
https://issues.apache.org/jira/browse/GEODE-8605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-8605:
--
Labels: pull-request-available (was: )
> Alter some GW senders attributes in runtime
> ---
>
> Key: GEODE-8605
> URL: https://issues.apache.org/jira/browse/GEODE-8605
> Project: Geode
> Issue Type: New Feature
> Components: gfsh, wan
>Reporter: Mario Ivanac
>Assignee: Mario Ivanac
>Priority: Major
> Labels: pull-request-available
>
> We would like to introduce new command "alter gateway-sender" which would
> update some parameters in runtime. For now parameters of interest are:
> * {color:#6a8759}alert-threshold{color}
> * {color:#6a8759}batch-size{color}
> * {color:#6a8759}batch-time-interval{color}
> * {color:#6a8759}...{color}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8605) Alter some GW senders attributes in runtime
[
https://issues.apache.org/jira/browse/GEODE-8605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17214764#comment-17214764
]
ASF GitHub Bot commented on GEODE-8605:
---
mivanac opened a new pull request #5630:
URL: https://github.com/apache/geode/pull/5630
WIP: Do not review
Thank you for submitting a contribution to Apache Geode.
In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:
### For all changes:
- [*] Is there a JIRA ticket associated with this PR? Is it referenced in
the commit message?
- [*] Has your PR been rebased against the latest commit within the target
branch (typically `develop`)?
- [*] Is your initial contribution a single, squashed commit?
- [*] Does `gradlew build` run cleanly?
- [*] Have you written or updated unit tests to verify your changes?
- [ ] If adding new dependencies to the code, are these dependencies
licensed in a way that is compatible for inclusion under [ASF
2.0](http://www.apache.org/legal/resolved.html#category-a)?
### Note:
Please ensure that once the PR is submitted, check Concourse for build
issues and
submit an update to your PR as soon as possible. If you need help, please
send an
email to d...@geode.apache.org.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Alter some GW senders attributes in runtime
> ---
>
> Key: GEODE-8605
> URL: https://issues.apache.org/jira/browse/GEODE-8605
> Project: Geode
> Issue Type: New Feature
> Components: gfsh, wan
>Reporter: Mario Ivanac
>Assignee: Mario Ivanac
>Priority: Major
>
> We would like to introduce new command "alter gateway-sender" which would
> update some parameters in runtime. For now parameters of interest are:
> * {color:#6a8759}alert-threshold{color}
> * {color:#6a8759}batch-size{color}
> * {color:#6a8759}batch-time-interval{color}
> * {color:#6a8759}...{color}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8157) Write "drop proxy test" for C# (clicache)
[ https://issues.apache.org/jira/browse/GEODE-8157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17214746#comment-17214746 ] ASF GitHub Bot commented on GEODE-8157: --- lgtm-com[bot] commented on pull request #674: URL: https://github.com/apache/geode-native/pull/674#issuecomment-709371440 This pull request **introduces 2 alerts** when merging 1e127260f15fa8bc2d37642d7a1a0d6738f15edf into 7c30a8cdbf4de1d7ae34309f5094dea261a8ce1e - [view on LGTM.com](https://lgtm.com/projects/g/apache/geode-native/rev/pr-5e76a7b4d8c50503ff4f8e7f2e722888dd18a756) **new alerts:** * 2 for Useless assignment to local variable This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Write "drop proxy test" for C# (clicache) > - > > Key: GEODE-8157 > URL: https://issues.apache.org/jira/browse/GEODE-8157 > Project: Geode > Issue Type: New Feature > Components: native client >Reporter: Blake Bender >Priority: Major > Labels: pull-request-available > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8157) Write "drop proxy test" for C# (clicache)
[ https://issues.apache.org/jira/browse/GEODE-8157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17214710#comment-17214710 ] ASF GitHub Bot commented on GEODE-8157: --- mmartell commented on a change in pull request #674: URL: https://github.com/apache/geode-native/pull/674#discussion_r505559467 ## File path: clicache/acceptance-test/SNITests.cs ## @@ -90,7 +91,18 @@ private int ParseProxyPort(string proxyString) return Int32.Parse(portNumberString); } -[Fact] + + //private Task PutAsync(IRegion region) Review comment: Lifted me for at least the remainder of this day you have. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Write "drop proxy test" for C# (clicache) > - > > Key: GEODE-8157 > URL: https://issues.apache.org/jira/browse/GEODE-8157 > Project: Geode > Issue Type: New Feature > Components: native client >Reporter: Blake Bender >Priority: Major > Labels: pull-request-available > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8615) Update gitignore with tools/gnmsg entries
[ https://issues.apache.org/jira/browse/GEODE-8615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-8615: -- Labels: pull-request-available (was: ) > Update gitignore with tools/gnmsg entries > - > > Key: GEODE-8615 > URL: https://issues.apache.org/jira/browse/GEODE-8615 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Alberto Bustamante Reyes >Assignee: Alberto Bustamante Reyes >Priority: Major > Labels: pull-request-available > > Following entries should be added to gitignore: > * /tools/gnmsg/.idea/ > * /tools/gnmsg/__pycache__/ -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8615) Update gitignore with tools/gnmsg entries
[ https://issues.apache.org/jira/browse/GEODE-8615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17214586#comment-17214586 ] ASF GitHub Bot commented on GEODE-8615: --- alb3rtobr opened a new pull request #677: URL: https://github.com/apache/geode-native/pull/677 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Update gitignore with tools/gnmsg entries > - > > Key: GEODE-8615 > URL: https://issues.apache.org/jira/browse/GEODE-8615 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Alberto Bustamante Reyes >Assignee: Alberto Bustamante Reyes >Priority: Major > > Following entries should be added to gitignore: > * /tools/gnmsg/.idea/ > * /tools/gnmsg/__pycache__/ -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8615) Update gitignore with tools/gnmsg entries
Alberto Bustamante Reyes created GEODE-8615: --- Summary: Update gitignore with tools/gnmsg entries Key: GEODE-8615 URL: https://issues.apache.org/jira/browse/GEODE-8615 Project: Geode Issue Type: Improvement Components: native client Reporter: Alberto Bustamante Reyes Following entries should be added to gitignore: * /tools/gnmsg/.idea/ * /tools/gnmsg/__pycache__/ -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-8615) Update gitignore with tools/gnmsg entries
[ https://issues.apache.org/jira/browse/GEODE-8615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Bustamante Reyes reassigned GEODE-8615: --- Assignee: Alberto Bustamante Reyes > Update gitignore with tools/gnmsg entries > - > > Key: GEODE-8615 > URL: https://issues.apache.org/jira/browse/GEODE-8615 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Alberto Bustamante Reyes >Assignee: Alberto Bustamante Reyes >Priority: Major > > Following entries should be added to gitignore: > * /tools/gnmsg/.idea/ > * /tools/gnmsg/__pycache__/ -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8614) Provide an specific client-side exception for server LowMemoryException
Mario Salazar de Torres created GEODE-8614:
--
Summary: Provide an specific client-side exception for server
LowMemoryException
Key: GEODE-8614
URL: https://issues.apache.org/jira/browse/GEODE-8614
Project: Geode
Issue Type: Improvement
Components: native client
Affects Versions: 1.13.0, 1.12.0, 1.11.0
Reporter: Mario Salazar de Torres
*AS AN* native client contributor
*I WANT* to have a client-side exception for LowMemoryException
*SO THAT* I can nofity accordingly from the client-side upon server
memory-depletion.
---
*Additional information*
This is the callstack of the LowMemoryException:
{noformat}
[error 2020/10/13 09:54:14.401405 UTC 140522117220352] Region::put: An
exception (org.apache.geode.cache.LowMemoryException: PartitionedRegion:
/part_a cannot process operation on key foo|0 because members
[192.168.240.14(dms-server-1:1):41000] are running low on memory at
org.apache.geode.internal.cache.partitioned.RegionAdvisor.checkIfBucketSick(RegionAdvisor.java:482)
at
org.apache.geode.internal.cache.PartitionedRegion.checkIfAboveThreshold(PartitionedRegion.java:2278)
at
org.apache.geode.internal.cache.PartitionedRegion.putInBucket(PartitionedRegion.java:2982)
at
org.apache.geode.internal.cache.PartitionedRegion.virtualPut(PartitionedRegion.java:2212)
at
org.apache.geode.internal.cache.LocalRegionDataView.putEntry(LocalRegionDataView.java:170)
at
org.apache.geode.internal.cache.LocalRegion.basicUpdate(LocalRegion.java:5573)
at
org.apache.geode.internal.cache.LocalRegion.basicUpdate(LocalRegion.java:5533)
at
org.apache.geode.internal.cache.LocalRegion.basicBridgePut(LocalRegion.java:5212)
at
org.apache.geode.internal.cache.tier.sockets.command.Put65.cmdExecute(Put65.java:411)
at
org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:183)
at
org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMessage(ServerConnection.java:848)
at
org.apache.geode.internal.cache.tier.sockets.OriginalServerConnection.doOneMessage(OriginalServerConnection.java:72)
at
org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1212)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at
org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.lambda$initializeServerConnectionThreadPool$3(AcceptorImpl.java:676)
at
org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:119)
at java.base/java.lang.Thread.run(Thread.java:834) ) happened at remote server.
{noformat}
Idea would be to modify *ThinClientRegion::handleServerException* in order to
return a new error and later on, map it to a new created exception
*Suggestions*
The new exception could be called:
* CacheServerLowMemoryException
* ...
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-8613) Remove exclusive access to pool connection creation/removal in native client
[ https://issues.apache.org/jira/browse/GEODE-8613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Gomez reassigned GEODE-8613: Assignee: Alberto Gomez > Remove exclusive access to pool connection creation/removal in native client > > > Key: GEODE-8613 > URL: https://issues.apache.org/jira/browse/GEODE-8613 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > > The Apache Geode C++ native client uses a mutex to grant exclusive access to > the code that creates or removes pool connections (mutex_ member in > ThinClientPoolDM class). The reason behind seems to be to perform atomically > the creation of the connection and the update of the number of connections > (m_poolSize) of the pool so that the number of connections in the pool and > the counter are always aligned. > This mutex is also used to protect the concurrent access to the connection > queue structure (ConnectionQueue class). > So, the mutex is used for two different purposes. > Getting this mutex while creating/removing a pool connection has an impact in > the performance of the client because connections cannot be created > concurrently but there are also negative side effects that could lead to a > freeze of the client if the connection creation is taking a long time (for > example when the DNS is not available and name resolution calls take seconds > to be answered). > A particularly problematic case is that when a minimum number of connections > has been configured in the client, loadconditioning or connection expiration > is configured and the DNS becomes unavailable. If at a given point in time > the number of connections in the pool is lower than the minimum configured, > the thread that restores the minimum number of connections will try to create > a new connection and will not release the mutex until it has finished. This > will block other threads trying to get a connection from the queue > unnecessarily. > In this ticket, it is proposed to remove the locking of the mutex when the > connection is created or removed. An alternative could be to create a new > mutex for the creation or removal of connections so that the access to the > ConnectionQueue is not affected by the creation/removal of connections but I > do not consider it necessary just to maintain consistent (and not only > eventually consistent) the number of connection of the pool and the counter > of the connections (m_poolSize). > Note that this ticket does not propose to remove the use of the mutex to > access the ConnectionQueue. This will still be necessary to protect > concurrent access to the connection queue data structure. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8613) Remove exclusive access to pool connection creation/removal in native client
Alberto Gomez created GEODE-8613: Summary: Remove exclusive access to pool connection creation/removal in native client Key: GEODE-8613 URL: https://issues.apache.org/jira/browse/GEODE-8613 Project: Geode Issue Type: Improvement Components: native client Reporter: Alberto Gomez The Apache Geode C++ native client uses a mutex to grant exclusive access to the code that creates or removes pool connections (mutex_ member in ThinClientPoolDM class). The reason behind seems to be to perform atomically the creation of the connection and the update of the number of connections (m_poolSize) of the pool so that the number of connections in the pool and the counter are always aligned. This mutex is also used to protect the concurrent access to the connection queue structure (ConnectionQueue class). So, the mutex is used for two different purposes. Getting this mutex while creating/removing a pool connection has an impact in the performance of the client because connections cannot be created concurrently but there are also negative side effects that could lead to a freeze of the client if the connection creation is taking a long time (for example when the DNS is not available and name resolution calls take seconds to be answered). A particularly problematic case is that when a minimum number of connections has been configured in the client, loadconditioning or connection expiration is configured and the DNS becomes unavailable. If at a given point in time the number of connections in the pool is lower than the minimum configured, the thread that restores the minimum number of connections will try to create a new connection and will not release the mutex until it has finished. This will block other threads trying to get a connection from the queue unnecessarily. In this ticket, it is proposed to remove the locking of the mutex when the connection is created or removed. An alternative could be to create a new mutex for the creation or removal of connections so that the access to the ConnectionQueue is not affected by the creation/removal of connections but I do not consider it necessary just to maintain consistent (and not only eventually consistent) the number of connection of the pool and the counter of the connections (m_poolSize). Note that this ticket does not propose to remove the use of the mutex to access the ConnectionQueue. This will still be necessary to protect concurrent access to the connection queue data structure. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8293) activeCQCount has negative value
[
https://issues.apache.org/jira/browse/GEODE-8293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17214453#comment-17214453
]
ASF GitHub Bot commented on GEODE-8293:
---
mkevo commented on a change in pull request #5620:
URL: https://github.com/apache/geode/pull/5620#discussion_r505185330
##
File path: geode-docs/reference/statistics_list.html.md.erb
##
@@ -553,7 +553,12 @@ These statistics are in a client and they describe one of
the client’s connect
## Continuous Querying (CqQueryStats)
-These statistics are for continuous querying information. The statistics are:
+These statistics are for continuous querying information.
+
+**Note:**
+The subscription redundancy changes CQS_ACTIVE, CQS_STOPPED and CQS_CLOSED
count on partitioned region
Review comment:
Hi @karensmolermiller,
After talking with @agingade , we found solution for this issue, but there
must be added this note to inform users that changing subscription redundancy
level on partitioned region will have effect on these counters as they will
change depending on subscription redundancy level.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> activeCQCount has negative value
>
>
> Key: GEODE-8293
> URL: https://issues.apache.org/jira/browse/GEODE-8293
> Project: Geode
> Issue Type: Bug
> Components: statistics
>Reporter: Mario Kevo
>Assignee: Mario Kevo
>Priority: Major
> Labels: pull-request-available
>
> In case you have more than one server in the system and you close CQ there
> will be negative value of active cqs.
> The problem is when you started more than one server and execute cq on it. In
> that case we got incCqsActive on one server, but when it is closed we have
> decCqsActive on both servers.
> {code:java}
> gfsh>show metrics --categories=query
> Cluster-wide MetricsCategory | Metric | Value
> | | -
> query| activeCQCount| 1
> | queryRequestRate | 0.0
> {code}
> After cq is closed or stopped:
> {code:java}
> gfsh>show metrics --categories=query
> Cluster-wide Metrics
> Category | Metric | Value
> | | -
> query| activeCQCount| -1
> | queryRequestRate | 0.0
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
