[jira] [Updated] (GEODE-9901) Failing upgrade-test after Log4j 2.15 bump to 2.16
[ https://issues.apache.org/jira/browse/GEODE-9901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dick Cavender updated GEODE-9901: - Fix Version/s: (was: 1.13.6) > Failing upgrade-test after Log4j 2.15 bump to 2.16 > -- > > Key: GEODE-9901 > URL: https://issues.apache.org/jira/browse/GEODE-9901 > Project: Geode > Issue Type: Bug >Reporter: Steve Sienkowski >Priority: Major > > A number of tests are failing in the `upgrade-test-openjdk11` job of the 1.13 > pipeline. > These issues are characterized by an error message of > `java.rmi.ConnectException: Connection refused to host:` > First failure here: > [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-13-main/jobs/upgrade-test-openjdk11/builds/14] > Git commit introducing upgrade of log4j 2.15 to 2.16: > [https://github.com/apache/geode/commit/224c996daa8bdd5243399e7d929120ad99c39fe3] > Relevant JIRA: https://issues.apache.org/jira/browse/GEODE-9898 > > > > Example error message: > > Task :geode-gfsh:upgradeTest > org.apache.geode.management.GfshRebalanceCommandCompatibilityTest > > whenCurrentVersionLocatorsExecuteRebalanceOnOldServersThenItMustSucceed[1.12.0] > FAILED > org.apache.geode.test.dunit.RMIException: While invoking > org.apache.geode.test.dunit.IgnoredException$1.run in VM 0 running on Host > c9ef3b85f95a with 4 VMs with version 1.12.0 > Caused by: > java.rmi.ConnectException: Connection refused to host: 172.17.0.37; > nested exception is: > java.net.ConnectException: Connection refused (Connection refused) > Caused by: > java.net.ConnectException: Connection refused (Connection refused) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9901) Failing upgrade-test after Log4j 2.15 bump to 2.16
[ https://issues.apache.org/jira/browse/GEODE-9901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dick Cavender updated GEODE-9901: - Affects Version/s: 1.13.6 > Failing upgrade-test after Log4j 2.15 bump to 2.16 > -- > > Key: GEODE-9901 > URL: https://issues.apache.org/jira/browse/GEODE-9901 > Project: Geode > Issue Type: Bug >Affects Versions: 1.13.6 >Reporter: Steve Sienkowski >Priority: Major > > A number of tests are failing in the `upgrade-test-openjdk11` job of the 1.13 > pipeline. > These issues are characterized by an error message of > `java.rmi.ConnectException: Connection refused to host:` > First failure here: > [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-13-main/jobs/upgrade-test-openjdk11/builds/14] > Git commit introducing upgrade of log4j 2.15 to 2.16: > [https://github.com/apache/geode/commit/224c996daa8bdd5243399e7d929120ad99c39fe3] > Relevant JIRA: https://issues.apache.org/jira/browse/GEODE-9898 > > > > Example error message: > > Task :geode-gfsh:upgradeTest > org.apache.geode.management.GfshRebalanceCommandCompatibilityTest > > whenCurrentVersionLocatorsExecuteRebalanceOnOldServersThenItMustSucceed[1.12.0] > FAILED > org.apache.geode.test.dunit.RMIException: While invoking > org.apache.geode.test.dunit.IgnoredException$1.run in VM 0 running on Host > c9ef3b85f95a with 4 VMs with version 1.12.0 > Caused by: > java.rmi.ConnectException: Connection refused to host: 172.17.0.37; > nested exception is: > java.net.ConnectException: Connection refused (Connection refused) > Caused by: > java.net.ConnectException: Connection refused (Connection refused) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (GEODE-9060) checkMyStateOnMemebers is better not to change the replicates
[ https://issues.apache.org/jira/browse/GEODE-9060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dick Cavender closed GEODE-9060. > checkMyStateOnMemebers is better not to change the replicates > - > > Key: GEODE-9060 > URL: https://issues.apache.org/jira/browse/GEODE-9060 > Project: Geode > Issue Type: Bug >Reporter: Xiaojian Zhou >Assignee: Xiaojian Zhou >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Fix For: 1.12.8, 1.13.7, 1.14.3, 1.15.0 > > > This is an enhancement to previous GEODE-9003. > The previous fix will remove the members in replicates if it cannot recognize > current member, thus these removed members will not acting as GII provider > candidates. The fix is correct. > However, Dan suggested to keep the replicates as is to be more conservative. > These members will still act as GII provider candidates even they cannot > recognize current member due to the split-brain. Conceptually these members > should be the same as other online members. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (GEODE-9905) bump log4j to 2.17.1
[ https://issues.apache.org/jira/browse/GEODE-9905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dick Cavender closed GEODE-9905. > bump log4j to 2.17.1 > > > Key: GEODE-9905 > URL: https://issues.apache.org/jira/browse/GEODE-9905 > Project: Geode > Issue Type: Improvement > Components: core >Reporter: Owen Nichols >Assignee: Kirk Lund >Priority: Major > Labels: pull-request-available > Fix For: 1.12.8, 1.13.7, 1.14.3, 1.15.0 > > > Although Geode is not vulnerable to the log4j recursive substitution issue > fixed in 2.17.0, it's probably a good idea to keep up with the latest log4j > security patches -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (GEODE-9901) Failing upgrade-test after Log4j 2.15 bump to 2.16
[ https://issues.apache.org/jira/browse/GEODE-9901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dick Cavender closed GEODE-9901. > Failing upgrade-test after Log4j 2.15 bump to 2.16 > -- > > Key: GEODE-9901 > URL: https://issues.apache.org/jira/browse/GEODE-9901 > Project: Geode > Issue Type: Bug >Affects Versions: 1.13.6 >Reporter: Steve Sienkowski >Priority: Major > Fix For: 1.12.8, 1.13.7, 1.14.3, 1.15.0 > > > A number of tests are failing in the `upgrade-test-openjdk11` job of the 1.13 > pipeline. > These issues are characterized by an error message of > `java.rmi.ConnectException: Connection refused to host:` > First failure here: > [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-13-main/jobs/upgrade-test-openjdk11/builds/14] > Git commit introducing upgrade of log4j 2.15 to 2.16: > [https://github.com/apache/geode/commit/224c996daa8bdd5243399e7d929120ad99c39fe3] > Relevant JIRA: https://issues.apache.org/jira/browse/GEODE-9898 > > > > Example error message: > > Task :geode-gfsh:upgradeTest > org.apache.geode.management.GfshRebalanceCommandCompatibilityTest > > whenCurrentVersionLocatorsExecuteRebalanceOnOldServersThenItMustSucceed[1.12.0] > FAILED > org.apache.geode.test.dunit.RMIException: While invoking > org.apache.geode.test.dunit.IgnoredException$1.run in VM 0 running on Host > c9ef3b85f95a with 4 VMs with version 1.12.0 > Caused by: > java.rmi.ConnectException: Connection refused to host: 172.17.0.37; > nested exception is: > java.net.ConnectException: Connection refused (Connection refused) > Caused by: > java.net.ConnectException: Connection refused (Connection refused) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-10099) release 1.12.9
Dick Cavender created GEODE-10099: - Summary: release 1.12.9 Key: GEODE-10099 URL: https://issues.apache.org/jira/browse/GEODE-10099 Project: Geode Issue Type: Task Components: release Reporter: Dick Cavender Release to incorporate GEODE-10093. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-10100) release 1.13.8
Dick Cavender created GEODE-10100: - Summary: release 1.13.8 Key: GEODE-10100 URL: https://issues.apache.org/jira/browse/GEODE-10100 Project: Geode Issue Type: Task Components: release Reporter: Dick Cavender Release to incorporate GEODE-10093 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-10101) release 1.14.4
Dick Cavender created GEODE-10101: - Summary: release 1.14.4 Key: GEODE-10101 URL: https://issues.apache.org/jira/browse/GEODE-10101 Project: Geode Issue Type: Task Components: release Reporter: Dick Cavender Release to incorporate GEODE-10093 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-10099) release 1.12.9
[ https://issues.apache.org/jira/browse/GEODE-10099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dick Cavender resolved GEODE-10099. --- Resolution: Resolved > release 1.12.9 > -- > > Key: GEODE-10099 > URL: https://issues.apache.org/jira/browse/GEODE-10099 > Project: Geode > Issue Type: Task > Components: release >Reporter: Dick Cavender >Priority: Major > Labels: pull-request-available > > Release to incorporate GEODE-10093. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-10101) release 1.14.4
[ https://issues.apache.org/jira/browse/GEODE-10101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dick Cavender resolved GEODE-10101. --- Fix Version/s: 1.14.5 1.15.0 Resolution: Fixed > release 1.14.4 > -- > > Key: GEODE-10101 > URL: https://issues.apache.org/jira/browse/GEODE-10101 > Project: Geode > Issue Type: Task > Components: release >Reporter: Dick Cavender >Priority: Major > Labels: pull-request-available > Fix For: 1.14.5, 1.15.0 > > > Release to incorporate GEODE-10093 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (GEODE-10093) DeltaSession getAttribute method logs an NPE and returns unserialized value when called on attribute with null value
[ https://issues.apache.org/jira/browse/GEODE-10093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dick Cavender closed GEODE-10093. - > DeltaSession getAttribute method logs an NPE and returns unserialized value > when called on attribute with null value > > > Key: GEODE-10093 > URL: https://issues.apache.org/jira/browse/GEODE-10093 > Project: Geode > Issue Type: Bug > Components: http session >Affects Versions: 1.12.2, 1.13.3, 1.14.0, 1.15.0 >Reporter: Benjamin P Ross >Assignee: Benjamin P Ross >Priority: Major > Labels: needsTriage, pull-request-available > Fix For: 1.12.9, 1.13.8, 1.14.4, 1.15.0 > > > Under certain circumstances, a null value can be set for an attribute which > then throws an NPE when trying to add it to the local map during a > getAttribute call on the session. Prior to 1.12.2 we were responding to this > by removing the entry entirely from the local map which is consistent with > what the base Session class for Catalina does, but starting with 1.12.2 > onward this results in an error message being displayed and the serialized > value being returned rather than the unserialized value. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (GEODE-9528) CI Failure: DistributionAdvisorIntegrationTest > verifyMembershipListenerIsRemovedAfterForceDisconnect
[
https://issues.apache.org/jira/browse/GEODE-9528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dick Cavender closed GEODE-9528.
> CI Failure: DistributionAdvisorIntegrationTest >
> verifyMembershipListenerIsRemovedAfterForceDisconnect
> --
>
> Key: GEODE-9528
> URL: https://issues.apache.org/jira/browse/GEODE-9528
> Project: Geode
> Issue Type: Bug
> Components: membership, tests
>Affects Versions: 1.12.5, 1.13.5, 1.14.0
>Reporter: Owen Nichols
>Assignee: Barrett Oglesby
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.12.9, 1.13.8, 1.14.4, 1.15.0
>
>
> {noformat}
> org.apache.geode.distributed.internal.DistributionAdvisorIntegrationTest >
> verifyMembershipListenerIsRemovedAfterForceDisconnect FAILED
> org.junit.ComparisonFailure: expected:<[fals]e> but was:<[tru]e>
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.distributed.internal.DistributionAdvisorIntegrationTest.verifyMembershipListenerIsRemovedAfterForceDisconnect(DistributionAdvisorIntegrationTest.java:57)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (GEODE-10062) Update Native Client Docs to minimize redirects
[ https://issues.apache.org/jira/browse/GEODE-10062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dick Cavender closed GEODE-10062. - > Update Native Client Docs to minimize redirects > --- > > Key: GEODE-10062 > URL: https://issues.apache.org/jira/browse/GEODE-10062 > Project: Geode > Issue Type: Improvement > Components: docs, native client >Affects Versions: 1.14.3 >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Major > Labels: pull-request-available > Fix For: 1.14.4, 1.15.0 > > > Geode Native Client doc sources could be improved for ease of building and > use by reducing dependency on the ruby redirect feature, through measures > such as: > - Replace ruby redirects, where feasible, with template variables, e.g. links > to API docs and server guide > - Standardizing template variables, e.g. use 'serverman' consistently, > retiring other alternatives such as 'geodeman' -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (GEODE-9817) Allow analyze serializables tests to provide custom source set paths to ClassAnalysisRule
[ https://issues.apache.org/jira/browse/GEODE-9817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dick Cavender closed GEODE-9817. > Allow analyze serializables tests to provide custom source set paths to > ClassAnalysisRule > - > > Key: GEODE-9817 > URL: https://issues.apache.org/jira/browse/GEODE-9817 > Project: Geode > Issue Type: Wish > Components: tests >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Labels: pull-request-available > Fix For: 1.14.4, 1.15.0 > > > In order to make SanctionedSerializablesService and the related tests to be > more pluggable by external modules, I need to make changes to allow analyze > serializables tests to provide custom source set paths to ClassAnalysisRule. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (GEODE-9372) DistributionStats needs a stat for create sender time to help diagnose data replication spikes
[ https://issues.apache.org/jira/browse/GEODE-9372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dick Cavender closed GEODE-9372. > DistributionStats needs a stat for create sender time to help diagnose data > replication spikes > -- > > Key: GEODE-9372 > URL: https://issues.apache.org/jira/browse/GEODE-9372 > Project: Geode > Issue Type: Improvement > Components: statistics >Reporter: Barrett Oglesby >Assignee: Barrett Oglesby >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Fix For: 1.12.9, 1.13.8, 1.14.4, 1.15.0 > > Attachments: > PartitionedRegionStats_sendReplicationTime_DistributionStats_sendersTO.gif > > > While debugging an issue with sendReplicationTime, we realized it was all due > to sender creation time. > A statistic for that time would have been very useful. > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (GEODE-9923) User Guide: add Log Message troubleshooting section
[ https://issues.apache.org/jira/browse/GEODE-9923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dick Cavender closed GEODE-9923. > User Guide: add Log Message troubleshooting section > --- > > Key: GEODE-9923 > URL: https://issues.apache.org/jira/browse/GEODE-9923 > Project: Geode > Issue Type: Improvement > Components: docs >Affects Versions: 1.14.2 >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Major > Labels: pull-request-available > Fix For: 1.12.9, 1.13.8, 1.14.4, 1.15.0 > > > GemFire support team (who are also Geode community members) have compiled a > troubleshooting guide that maps log messages to suggested solutions. > They have contributed this to Geode in the form of a Google doc. > Reformat the Google doc and add it to the Geode user guide. There's an > existing section under Managing Apache Geode called Troubleshooting and > System Recovery that would be a good location for this material. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (GEODE-9973) Documentation: socket-lease-time is not used to return sockets to a pool but to close them
[ https://issues.apache.org/jira/browse/GEODE-9973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dick Cavender closed GEODE-9973. > Documentation: socket-lease-time is not used to return sockets to a pool but > to close them > -- > > Key: GEODE-9973 > URL: https://issues.apache.org/jira/browse/GEODE-9973 > Project: Geode > Issue Type: Bug > Components: docs >Affects Versions: 1.12.9, 1.13.8, 1.14.4, 1.15.0 >Reporter: Alberto Gomez >Assignee: Donal Evans >Priority: Major > Labels: pull-request-available > Fix For: 1.12.9, 1.13.8, 1.14.4, 1.15.0 > > > The "Making sure you have enough sockets" Geode documentation section says > the following about socket-lease-time (check underlined sentence): > > Peer-to-peer. For peer-to-peer threads that do not share sockets, you can use > the socket-lease-time to make sure that no socket sits idle for too long. > +When a socket that belongs to an individual thread remains unused for this > time period, the system automatically returns it to the pool.+ The next time > the thread needs a socket, it creates a new socket. > > Actually, the system automatically closes the connection in the situation > described instead of returning it to any pool. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (GEODE-9819) Client socket leak in CacheClientNotifier.registerClientInternal when error conditions occur for the durable client
[
https://issues.apache.org/jira/browse/GEODE-9819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dick Cavender closed GEODE-9819.
> Client socket leak in CacheClientNotifier.registerClientInternal when error
> conditions occur for the durable client
> ---
>
> Key: GEODE-9819
> URL: https://issues.apache.org/jira/browse/GEODE-9819
> Project: Geode
> Issue Type: Bug
> Components: client/server, core
>Affects Versions: 1.12.5, 1.13.4, 1.14.0, 1.15.0
>Reporter: Leon Finker
>Assignee: Darrel Schneider
>Priority: Critical
> Labels: GeodeOperationAPI, blocks-1.15.0, pull-request-available
> Fix For: 1.12.9, 1.13.8, 1.14.4, 1.15.0
>
>
> In CacheClientNotifier.registerClientInternal client socket can be left half
> open and not properly closed when error conditions occur. Such as the case of:
> {code:java}
> } else {
> // The existing proxy is already running (which means that another
> // client is already using this durable id.
> unsuccessfulMsg =
> String.format(
> "The requested durable client has the same identifier ( %s ) as an
> existing durable client ( %s ). Duplicate durable clients are not allowed.",
> clientProxyMembershipID.getDurableId(), cacheClientProxy);
> logger.warn(unsuccessfulMsg);
> // Set the unsuccessful response byte.
> responseByte = Handshake.REPLY_EXCEPTION_DUPLICATE_DURABLE_CLIENT;
> } {code}
> It considers the current client connect attempt to have failed. It writes
> this response back to client: REPLY_EXCEPTION_DUPLICATE_DURABLE_CLIENT. This
> will cause the client to throw ServerRefusedConnectionException. What seems
> wrong about this method is that even though it sets "unsuccessfulMsg" and
> correctly sends back a handshake saying the client is rejected, it does not
> throw an exception and it does not close "socket". I think right before it
> calls performPostAuthorization it should do the followiing:
> {code:java}
> if (unsuccessfulMsg != null) {
> try {
> socket.close();
> } catch (IOException ignore) {
> }
> } else {
> performPostAuthorization(...)
> }{code}
> Full discussion details can be found at
> https://markmail.org/thread/2gqmbq2m57pz7pxu
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (GEODE-9990) Geode should handle certain DiskAccessException due to CacheClosedException when creating bucket
[
https://issues.apache.org/jira/browse/GEODE-9990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dick Cavender closed GEODE-9990.
> Geode should handle certain DiskAccessException due to CacheClosedException
> when creating bucket
>
>
> Key: GEODE-9990
> URL: https://issues.apache.org/jira/browse/GEODE-9990
> Project: Geode
> Issue Type: Bug
> Components: persistence
>Affects Versions: 1.15.0
>Reporter: Eric Shu
>Assignee: Joris Melchior
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
> Fix For: 1.14.4, 1.15.0
>
>
> This exception is thrown to the node that tries to create the bucket to
> prevent it trying to create the bucket to next available server and fail the
> entry operation.
> {noformat}
> org.apache.geode.cache.DiskAccessException: For DiskStore: diskStore: The
> disk store is closed
> at Remote Member
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
> in
> org.apache.geode.internal.cache.DiskInitFile.writeIFRecord(DiskInitFile.java:1313)
> at Remote Member
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
> in
> org.apache.geode.internal.cache.DiskInitFile.writeIFRecord(DiskInitFile.java:916)
> at Remote Member
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
> in
> org.apache.geode.internal.cache.DiskInitFile.markInitialized(DiskInitFile.java:2158)
> at Remote Member
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
> in
> org.apache.geode.internal.cache.DiskStoreImpl.setInitialized(DiskStoreImpl.java:3057)
> at Remote Member
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
> in
> org.apache.geode.internal.cache.AbstractDiskRegion.setInitialized(AbstractDiskRegion.java:606)
> at Remote Member
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
> in
> org.apache.geode.internal.cache.persistence.PersistenceAdvisorImpl.setOnline(PersistenceAdvisorImpl.java:392)
> at Remote Member
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
> in
> org.apache.geode.internal.cache.BucketPersistenceAdvisor.endBucketCreation(BucketPersistenceAdvisor.java:467)
> at Remote Member
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
> in
> org.apache.geode.internal.cache.PRHARedundancyProvider.endBucketCreationLocally(PRHARedundancyProvider.java:854)
> at Remote Member
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
> in
> org.apache.geode.internal.cache.PRHARedundancyProvider.endBucketCreation(PRHARedundancyProvider.java:813)
> at Remote Member
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
> in
> org.apache.geode.internal.cache.PRHARedundancyProvider.createBucketAtomically(PRHARedundancyProvider.java:701)
> at Remote Member
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
> in
> org.apache.geode.internal.cache.partitioned.CreateBucketMessage.operateOnPartitionedRegion(CreateBucketMessage.java:150)
> at Remote Member
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
> in
> org.apache.geode.internal.cache.partitioned.PartitionMessage.process(PartitionMessage.java:333)
> at Remote Member
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
> in
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376)
> at Remote Member
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
> in
> org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:441)
> at Remote Member
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
> in
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at Remote Member
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
> in
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at Remote Member
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
> in
> org.apache.geode.distributed.i
[jira] [Closed] (GEODE-5104) CI output git SHA when updating passing reference file.
[ https://issues.apache.org/jira/browse/GEODE-5104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dick Cavender closed GEODE-5104. Done > CI output git SHA when updating passing reference file. > --- > > Key: GEODE-5104 > URL: https://issues.apache.org/jira/browse/GEODE-5104 > Project: Geode > Issue Type: Task > Components: ci >Reporter: Sean Goller >Priority: Major > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > When concourse updates the file indicating the SHA that has passed all tests, > print it out. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-3942) Add concourse pipeline scripts
[
https://issues.apache.org/jira/browse/GEODE-3942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dick Cavender updated GEODE-3942:
-
Fix Version/s: 1.10.0
> Add concourse pipeline scripts
> --
>
> Key: GEODE-3942
> URL: https://issues.apache.org/jira/browse/GEODE-3942
> Project: Geode
> Issue Type: Improvement
> Components: ci
>Reporter: Anthony Baker
>Priority: Trivial
> Fix For: 1.10.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Add scripts for concourse pipelines. The initial jobs should just run
> {{gradle build}}.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Assigned] (GEODE-7093) CI script fails to update develop/highwater branch
[ https://issues.apache.org/jira/browse/GEODE-7093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dick Cavender reassigned GEODE-7093: Assignee: Jacob S. Barrett (was: Dick Cavender) > CI script fails to update develop/highwater branch > --- > > Key: GEODE-7093 > URL: https://issues.apache.org/jira/browse/GEODE-7093 > Project: Geode > Issue Type: Bug > Components: ci >Reporter: Bill Burcham >Assignee: Jacob S. Barrett >Priority: Major > > This build: > [https://concourse.gemfire-ci.info/teams/main/pipelines/sync-geode-support-develop/jobs/sync-geode-support-develop/builds/830] > > and subsequent ones fail with: > > To https://github.com/gemfire/geode-support.git > 86fd74db98..8e9b044702 HEAD -> develop > ! [rejected] develop/highwater -> develop/highwater (already exists) > error: failed to push some refs to > 'https://github.com/gemfire/geode-support.git' > hint: Updates were rejected because the tag already exists in the remote. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (GEODE-7093) CI script fails to update develop/highwater branch
[ https://issues.apache.org/jira/browse/GEODE-7093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16908686#comment-16908686 ] Dick Cavender commented on GEODE-7093: -- This needs to be determined by performance people. I'm not sure what this should be set to. > CI script fails to update develop/highwater branch > --- > > Key: GEODE-7093 > URL: https://issues.apache.org/jira/browse/GEODE-7093 > Project: Geode > Issue Type: Bug > Components: ci >Reporter: Bill Burcham >Assignee: Jacob S. Barrett >Priority: Major > > This build: > [https://concourse.gemfire-ci.info/teams/main/pipelines/sync-geode-support-develop/jobs/sync-geode-support-develop/builds/830] > > and subsequent ones fail with: > > To https://github.com/gemfire/geode-support.git > 86fd74db98..8e9b044702 HEAD -> develop > ! [rejected] develop/highwater -> develop/highwater (already exists) > error: failed to push some refs to > 'https://github.com/gemfire/geode-support.git' > hint: Updates were rejected because the tag already exists in the remote. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (GEODE-3967) if put hits concurrent modification exception should still notify serial gateway sender
[ https://issues.apache.org/jira/browse/GEODE-3967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dick Cavender updated GEODE-3967: - Fix Version/s: 1.10.0 > if put hits concurrent modification exception should still notify serial > gateway sender > --- > > Key: GEODE-3967 > URL: https://issues.apache.org/jira/browse/GEODE-3967 > Project: Geode > Issue Type: Bug > Components: wan >Reporter: xiaojian zhou >Assignee: xiaojian zhou >Priority: Major > Labels: pull-request-available > Fix For: 1.5.0, 1.10.0 > > Time Spent: 2h > Remaining Estimate: 0h > > In serial gateway sender, the event arrives at secondary will be put into > unprocessedMap and wait for event from primary queue to distribute over, then > remove it from the unprocessedMap. > If the put at primary member (member with primary queue) failed with CME, the > event in unprocessedMap will never be removed. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (GEODE-4806) Replace SimpleTestSecurityManager with SimpleSecurityManager
[ https://issues.apache.org/jira/browse/GEODE-4806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dick Cavender updated GEODE-4806: - Fix Version/s: 1.10.0 > Replace SimpleTestSecurityManager with SimpleSecurityManager > > > Key: GEODE-4806 > URL: https://issues.apache.org/jira/browse/GEODE-4806 > Project: Geode > Issue Type: Task > Components: security >Reporter: Jens Deppe >Assignee: Sean Goller >Priority: Major > Labels: starter > Fix For: 1.10.0 > > Time Spent: 20m > Remaining Estimate: 0h > > These classes appear to be the same. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (GEODE-5142) new Thread Monitoring Mechanism
[ https://issues.apache.org/jira/browse/GEODE-5142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dick Cavender updated GEODE-5142: - Fix Version/s: 1.10.0 > new Thread Monitoring Mechanism > --- > > Key: GEODE-5142 > URL: https://issues.apache.org/jira/browse/GEODE-5142 > Project: Geode > Issue Type: New Feature > Components: docs, management >Reporter: yossi reginiano >Assignee: Joey McAllister >Priority: Major > Labels: pull-request-available > Fix For: 1.10.0 > > Time Spent: 6h 40m > Remaining Estimate: 0h > > One of the most severe issues hitting our real time application is thread > stuck for multiple reasons, such as long lasting locks, deadlocks, threads > which wait for reply forever in case of packet drop issue etc... > Such kind of stuck are under Radar of the existing system health check > methods. In mission critical applications, this will be resulted as an > immediate outage. > Here we introduce thread monitoring mechanism, to detect threads which are > stuck for any reason. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (GEODE-5142) new Thread Monitoring Mechanism
[ https://issues.apache.org/jira/browse/GEODE-5142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dick Cavender updated GEODE-5142: - Fix Version/s: (was: 1.10.0) 1.9.0 > new Thread Monitoring Mechanism > --- > > Key: GEODE-5142 > URL: https://issues.apache.org/jira/browse/GEODE-5142 > Project: Geode > Issue Type: New Feature > Components: docs, management >Reporter: yossi reginiano >Assignee: Joey McAllister >Priority: Major > Labels: pull-request-available > Fix For: 1.9.0 > > Time Spent: 6h 40m > Remaining Estimate: 0h > > One of the most severe issues hitting our real time application is thread > stuck for multiple reasons, such as long lasting locks, deadlocks, threads > which wait for reply forever in case of packet drop issue etc... > Such kind of stuck are under Radar of the existing system health check > methods. In mission critical applications, this will be resulted as an > immediate outage. > Here we introduce thread monitoring mechanism, to detect threads which are > stuck for any reason. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (GEODE-5222) JMX metric exposed in an MBean
[ https://issues.apache.org/jira/browse/GEODE-5222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dick Cavender updated GEODE-5222: - Fix Version/s: 1.10.0 > JMX metric exposed in an MBean > -- > > Key: GEODE-5222 > URL: https://issues.apache.org/jira/browse/GEODE-5222 > Project: Geode > Issue Type: Improvement > Components: docs, persistence >Reporter: Nick Vallely >Assignee: Alberto Bustamante Reyes >Priority: Major > Fix For: 1.10.0 > > Time Spent: 3h 20m > Remaining Estimate: 0h > > Given I need to scale down or scale up my servers based on usage > When I setup my monitoring of JMX metrics through an MBean > Then I have the ability to see Disk Free Percentage > AND Disk Free in Bytes > AND Disk Used Percentage > AND Disk Used in Bytes -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (GEODE-5604) Make Geode build Gradle-5.0 ready
[ https://issues.apache.org/jira/browse/GEODE-5604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dick Cavender updated GEODE-5604: - Fix Version/s: 1.10.0 > Make Geode build Gradle-5.0 ready > - > > Key: GEODE-5604 > URL: https://issues.apache.org/jira/browse/GEODE-5604 > Project: Geode > Issue Type: Improvement > Components: build >Reporter: Robert Houghton >Priority: Major > Labels: pull-request-available > Fix For: 1.10.0 > > Time Spent: 3h 20m > Remaining Estimate: 0h > > Gradle is giving warnings about unsupported or deprecated features from our > 3.xx days. Clean them up. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (GEODE-5695) Update Sprockets to 3.7.2
[ https://issues.apache.org/jira/browse/GEODE-5695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dick Cavender updated GEODE-5695: - Fix Version/s: 1.7.0 > Update Sprockets to 3.7.2 > - > > Key: GEODE-5695 > URL: https://issues.apache.org/jira/browse/GEODE-5695 > Project: Geode > Issue Type: Task > Components: docs >Reporter: Joey McAllister >Assignee: Joey McAllister >Priority: Major > Fix For: 1.7.0 > > > Github says: > > We found a potential security vulnerability in a repository for which you > > have been granted security alert access. > > Known high severity security vulnerability detected in sprockets > > >=3.0.0,<3.7.2 defined in Gemfile.lock. > > Gemfile.lock update suggested: sprockets ~> 3.7.2. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (GEODE-5723) Only publish maven artifacts for SNAPSHOT versions.
[ https://issues.apache.org/jira/browse/GEODE-5723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dick Cavender updated GEODE-5723: - Fix Version/s: 1.8.0 > Only publish maven artifacts for SNAPSHOT versions. > --- > > Key: GEODE-5723 > URL: https://issues.apache.org/jira/browse/GEODE-5723 > Project: Geode > Issue Type: Improvement > Components: build >Reporter: Jacob S. Barrett >Priority: Major > Labels: pull-request-available > Fix For: 1.8.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (GEODE-5724) Fix javadocs for cache.util.ObjectSizer
[
https://issues.apache.org/jira/browse/GEODE-5724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dick Cavender updated GEODE-5724:
-
Fix Version/s: 1.10.0
> Fix javadocs for cache.util.ObjectSizer
> ---
>
> Key: GEODE-5724
> URL: https://issues.apache.org/jira/browse/GEODE-5724
> Project: Geode
> Issue Type: Bug
>Reporter: Karen Smoler Miller
>Assignee: Jason Huynh
>Priority: Minor
> Labels: SmallFeature, starter
> Fix For: 1.10.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The javadocs description for org.apache.geode.cache.util.ObjectSizer look
> like this:
> {{public interface ObjectSizer}}
> {{The sizer interface defines a method that when called returns the size of
> the object passed in. Implementations may return hardcoded values for object
> size if the implementation knows the object size for all objects that are
> likely to be cached. You should use a sizer with a
> EvictionAttributes.createLRUHeapAttributes(ObjectSizer) or
> EvictionAttributes.createLRUMemoryAttributes(ObjectSizer) if you want to use
> a faster or more accurate method of sizing than provided by the default
> object sizer, which is {#link SIZE_CLASS_ONCE}}
> Notice that the last part of the description is not right. It needs to be
> fixed.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (GEODE-5727) Export cluster-configuration does not work filename only
[
https://issues.apache.org/jira/browse/GEODE-5727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dick Cavender updated GEODE-5727:
-
Fix Version/s: 1.8.0
> Export cluster-configuration does not work filename only
>
>
> Key: GEODE-5727
> URL: https://issues.apache.org/jira/browse/GEODE-5727
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Bradford D. Boyle
>Assignee: Jinmei Liao
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.7.0, 1.8.0
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Using the latest Geode snapshot (aaac1e5cefe6ad7ca533a7ca87eef9dd779912e4),
> exporting cluster config with only a filename (no path) results in an error:
> {code}
> gfsh> start locator
> gfsh> start server
> gfsh> create region --name=test --type=PARTITION
> gfsh> export cluster-configuration --zip-file-name=cluster-config.zip
> Could not process command due to error. null
> {code}
> It does (sort of) work if you use a path:
> {code}
> gfsh> start locator
> gfsh> start server
> gfsh> create region --name=test --type=PARTITION
> gfsh> export cluster-configuration --zip-file-name=./cluster-config.zip
> {code}
> However, it appears that the cluster config file is written to both the
> specified path and the current working directory.
> {code}
> gfsh > export cluster-configuration --zip-file-name=/tmp/cluster-config.zip
> {code}
> {code}
> $ md5 /tmp/cluster-config.zip cluster-config.zip
> MD5 (/tmp/cluster-config.zip) = 50022493fa54f54da700adfc1a8f709c
> MD5 (cluster-config.zip) = 50022493fa54f54da700adfc1a8f709c
> {code}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (GEODE-5731) --hostname-for-client not working correclty
[
https://issues.apache.org/jira/browse/GEODE-5731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dick Cavender updated GEODE-5731:
-
Fix Version/s: 1.10.0
> --hostname-for-client not working correclty
> ---
>
> Key: GEODE-5731
> URL: https://issues.apache.org/jira/browse/GEODE-5731
> Project: Geode
> Issue Type: Bug
> Components: configuration, locator
>Affects Versions: 1.6.0
>Reporter: Alexander Murmann
>Assignee: Juan José Ramos Cassella
>Priority: Major
> Labels: SmallFeature
> Fix For: 1.10.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When starting a server cluster on EC2 and --hostname-for-client set for
> locator and server then the locator does not return the client-bind-address.
> Locator and server were initially started with
> {code:java}
> start locator --name=locator --port=4
> --properties-file=./gemfire.properties --initial-heap=256M
> --hostname-for-clients=ec2-12-345-678-90.compute-1.amazonaws.com
> start server --name=server1 --server-port=44666
> --properties-file=./gemfire.properties --initial-heap=256M
> --start-rest-api=true --http-service-port=7676
> {code}
> After some debugging the hostname-for-client on the server was also set to be
> the public IP address.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (GEODE-6122) Log4j core should be optional
[
https://issues.apache.org/jira/browse/GEODE-6122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dick Cavender updated GEODE-6122:
-
Fix Version/s: 1.10.0
> Log4j core should be optional
> -
>
> Key: GEODE-6122
> URL: https://issues.apache.org/jira/browse/GEODE-6122
> Project: Geode
> Issue Type: Bug
> Components: logging
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.9.0, 1.10.0
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> A simple test of Geode without log4j core on the classpath results in the
> following log statement and stack trace:
> {noformat}
> ERROR StatusLogger Log4j2 could not find a logging implementation. Please add
> log4j-core to the classpath. Using SimpleLogger to log to the console...
> {noformat}
> {noformat}
> java.lang.NoClassDefFoundError: org/apache/logging/log4j/core/Logger
> at
> org.apache.geode.internal.logging.log4j.Log4jAgent.getRootLoggerContext(Log4jAgent.java:89)
> at
> org.apache.geode.internal.logging.log4j.Log4jAgent.getConfiguration(Log4jAgent.java:93)
> at
> org.apache.geode.internal.logging.log4j.Log4jAgent.isUsingGemFireDefaultConfig(Log4jAgent.java:78)
> at
> org.apache.geode.internal.logging.log4j.Log4jAgent.shouldUpdateLogLevels(Log4jAgent.java:127)
> at
> org.apache.geode.internal.logging.log4j.Log4jAgent.configure(Log4jAgent.java:105)
> at
> org.apache.geode.internal.logging.Configuration.configChanged(Configuration.java:175)
> at
> org.apache.geode.internal.logging.Configuration.initialize(Configuration.java:164)
> at
> org.apache.geode.internal.logging.LoggingSession.createSession(LoggingSession.java:66)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:663)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.newInstance(InternalDistributedSystem.java:369)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.newInstance(InternalDistributedSystem.java:357)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.newInstance(InternalDistributedSystem.java:349)
> at
> org.apache.geode.distributed.DistributedSystem.connect(DistributedSystem.java:215)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:218)
> at
> io.github.kirklund.geode.GeodeApplicationIntegrationTest.setUp(GeodeApplicationIntegrationTest.java:34)
> 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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> Caused by: java.lang.ClassNotFoundException:
> org.apache.logging.log4j.core.Logger
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349)
[jira] [Updated] (GEODE-6383) Build scripting should not violate modularity.
[
https://issues.apache.org/jira/browse/GEODE-6383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dick Cavender updated GEODE-6383:
-
Fix Version/s: 1.9.0
> Build scripting should not violate modularity.
> --
>
> Key: GEODE-6383
> URL: https://issues.apache.org/jira/browse/GEODE-6383
> Project: Geode
> Issue Type: Improvement
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>Priority: Major
> Fix For: 1.9.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> In many portions of our build scripting, we use the invasive,
> modularity-breaking pattern of
> {noformat}
> subprojects {
> configureSomething
> }
> {noformat}
> This is particularly problematic when certain plugins or built-ins do not
> integrate well with each other, e.g, Gradle 5.2's {{java-platform}} needing
> to be applied before the {{java}} plugin.
> As a result, within a single subproject, it is very difficult to know
> (without prior experience) how the subproject is configured.
> This ticket is intended to be a "parent" ticket for jobs that fall into the
> following categories:
> * Converting a plugin-script in {{gradle/}} to a class extending
> {{Plugin}}.
> * Moving a plugin to belong to {{buildSrc}}
> * Converting invasive {{subproject [configuration]}} calls to be "opt-in" by
> the subprojects that require the configuration, such as the work done in
> GEODE-6237.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (GEODE-6400) Expose artifacts that are suitable for composite consumption.
[
https://issues.apache.org/jira/browse/GEODE-6400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dick Cavender updated GEODE-6400:
-
Fix Version/s: 1.9.0
> Expose artifacts that are suitable for composite consumption.
> -
>
> Key: GEODE-6400
> URL: https://issues.apache.org/jira/browse/GEODE-6400
> Project: Geode
> Issue Type: Sub-task
>Reporter: Patrick Rhomberg
>Priority: Major
> Fix For: 1.9.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Artifacts exposed to composite builds are defined in the legacy
> {{archives.artifacts}} publication style. However, this should / will / must
> not change what our actual publication artifacts (with respect to the
> {{maven-publish}} plugin).
> This is also an opportunity to streamline some of our more gnarly code in
> both {{geode-assembly}} and {{publish.gradle}}.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (GEODE-6532) Convert compile dependencies to implementation/api dependencies
[
https://issues.apache.org/jira/browse/GEODE-6532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dick Cavender updated GEODE-6532:
-
Fix Version/s: 1.9.0
> Convert compile dependencies to implementation/api dependencies
> ---
>
> Key: GEODE-6532
> URL: https://issues.apache.org/jira/browse/GEODE-6532
> Project: Geode
> Issue Type: Improvement
> Components: build, docs
>Reporter: Patrick Rhomberg
>Assignee: Dan Smith
>Priority: Major
> Fix For: 1.9.0
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> The {{compile}} configuration has been deprecated for some time. {{api}}
> will behave similarly, whereas {{implementation}} will appear to be a
> {{runtime}} dependency to consumers.
> This will require examining our public API so that we may correctly declare
> which dependencies are {{api}}. When a PR is made, an email should be sent
> to the dev@ and/or user@ lists warning that those consuming internal APIs
> (against best practice) may experience breakages if their own dependencies
> are not properly declared. Similarly, a release note on this topic could be
> helpful to those upgrading.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (GEODE-6561) Unable to reconnect when regions are configured with cluster config
[
https://issues.apache.org/jira/browse/GEODE-6561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dick Cavender updated GEODE-6561:
-
Fix Version/s: 1.10.0
> Unable to reconnect when regions are configured with cluster config
> ---
>
> Key: GEODE-6561
> URL: https://issues.apache.org/jira/browse/GEODE-6561
> Project: Geode
> Issue Type: Bug
> Components: configuration, management
>Reporter: Jens Deppe
>Priority: Major
> Fix For: 1.10.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
>
> Given that I have a region configured with cluster config and a server
> restarts, the following exception is likely to be thrown and the server will
> not be able to reconnect:
> {noformat}
> [vm2] java.lang.IllegalStateException: Cannot set idle timeout when
> statistics are disabled.
> [vm2] at
> org.apache.geode.internal.cache.AbstractRegion.setEntryIdleTimeout(AbstractRegion.java:1227)
> [vm2] at
> org.apache.geode.internal.cache.xmlcache.RegionCreation.setMutableAttributes(RegionCreation.java:194)
> [vm2] at
> org.apache.geode.internal.cache.xmlcache.RegionCreation.createRoot(RegionCreation.java:241)
> [vm2] at
> org.apache.geode.internal.cache.xmlcache.CacheCreation.initializeRegions(CacheCreation.java:635)
> [vm2] at
> org.apache.geode.internal.cache.xmlcache.CacheCreation.create(CacheCreation.java:577)
> [vm2] at
> org.apache.geode.internal.cache.xmlcache.CacheXmlParser.create(CacheXmlParser.java:337)
> [vm2] at
> org.apache.geode.internal.cache.GemFireCacheImpl.loadCacheXml(GemFireCacheImpl.java:4272)
> [vm2] at
> org.apache.geode.internal.cache.GemFireCacheImpl.initializeDeclarativeCache(GemFireCacheImpl.java:1388)
> [vm2] at
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1208)
> [vm2] at
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:207)
> [vm2] at
> org.apache.geode.distributed.internal.InternalDistributedSystem.reconnect(InternalDistributedSystem.java:2730)
> [vm2] at
> org.apache.geode.distributed.internal.InternalDistributedSystem.tryReconnect(InternalDistributedSystem.java:2496)
> [vm2] at
> org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect(InternalDistributedSystem.java:1312)
> [vm2] at
> org.apache.geode.distributed.internal.ClusterDistributionManager$DMListener.membershipFailure(ClusterDistributionManager.java:3424)
> [vm2] at
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.uncleanShutdown(GMSMembershipManager.java:1554)
> [vm2] at
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.lambda$forceDisconnect$3(GMSMembershipManager.java:2586)
> [vm2] at java.lang.Thread.run(Thread.java:748){noformat}
> As part of the reconnect, the original cache xml is saved at the beginning of
> the process. Reconnect goes through regular cache initialization which
> includes retrieving the cluster config from the locator and then applying the
> saved cache xml. In the above example, the cluster config looks like this:
> {noformat}
> [vm2]
> [vm2] http://geode.apache.org/schema/cache";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; version="1.0"
> xsi:schemaLocation="http://geode.apache.org/schema/cache
> http://geode.apache.org/schema/cache/cache-1.0.xsd";>
> [vm2]read-serialized="true">
> [vm2]
> [vm2]
> org.apache.geode.pdx.ReflectionBasedAutoSerializer
> [vm2]
> [vm2]
> ClusterConfigServerRestartWithJarDeployFunction.*
> [vm2]
> [vm2]
> [vm2]
> [vm2]
> [vm2]
> [vm2]
> [vm2] {noformat}
>
> And the saved cache.xml like this:
> {noformat}
> [vm2] [info 2019/03/26 06:24:52.841 PDT tid=0x4f]
> Initializing cache using generated description from old cache:
> [vm2]
> [vm2] http://www.w3.org/2001/XMLSchema-instance";
> xmlns="http://geode.apache.org/schema/cache";
> xsi:schemaLocation="http://geode.apache.org/schema/cache
> http://geode.apache.org/schema/cache/cache-1.0.xsd"; version="1.0"
> lock-lease="120" lock-timeout="60" search-timeout="300" is-server="true"
> copy-on-read="false">
> [vm2]
> [vm2]notify-by-subscription="true" socket-buffer-size="32768"
> max-connections="800" max-threads="0" maximum-message-count="23"
> message-time-to-live="180" bind-address="" load-poll-interval="5000"
> tcp-no-delay="true">
> [vm2]
> [vm2]
> org.apache.geode.cache.server.internal.ConnectionCountProbe
> [vm2]
> [vm2]
> [vm2]persistent="false">
> [vm2]
> [vm2]
> org.apache.geode.pdx.ReflectionBasedAutoSerializer
> [vm2]
> [vm2]
> ClusterConfigServerRestartWithJarDeployFunction.*
> [vm2]
> [vm2]
> [vm2]
> [vm2]
> [vm2] multicast-enabled="false" publisher
[jira] [Updated] (GEODE-6592) create jdbc-mapping need an optional parameter --if-not-exists
[ https://issues.apache.org/jira/browse/GEODE-6592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dick Cavender updated GEODE-6592: - Fix Version/s: 1.9.0 > create jdbc-mapping need an optional parameter --if-not-exists > -- > > Key: GEODE-6592 > URL: https://issues.apache.org/jira/browse/GEODE-6592 > Project: Geode > Issue Type: Bug >Reporter: xiaojian zhou >Assignee: Jianxia Chen >Priority: Major > Fix For: 1.9.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > create region command has an optional parameter --if-not-exists. create > jdbc-mapping command should have this parameter. Then when the jdbc-mapping > exists, the gfsh command will return success instead of error. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (GEODE-6600) Composite Meter Registry takes a lot of heap when regions created and destroyed
[ https://issues.apache.org/jira/browse/GEODE-6600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dick Cavender updated GEODE-6600: - Fix Version/s: 1.10.0 > Composite Meter Registry takes a lot of heap when regions created and > destroyed > --- > > Key: GEODE-6600 > URL: https://issues.apache.org/jira/browse/GEODE-6600 > Project: Geode > Issue Type: Bug > Components: statistics >Reporter: Michael Oleske >Assignee: Michael Oleske >Priority: Major > Fix For: 1.10.0 > > Time Spent: 40m > Remaining Estimate: 0h > > When creating and destroying lots of regions, we never remove region related > meters. This causes heap size to keep growing. > Please remove the meters -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (GEODE-6647) Move CreatePooledJndiBindingDUnitTest to a proper package
[
https://issues.apache.org/jira/browse/GEODE-6647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dick Cavender updated GEODE-6647:
-
Fix Version/s: 1.10.0
> Move CreatePooledJndiBindingDUnitTest to a proper package
> -
>
> Key: GEODE-6647
> URL: https://issues.apache.org/jira/browse/GEODE-6647
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Jianxia Chen
>Assignee: Jianxia Chen
>Priority: Major
> Fix For: 1.10.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {{CreatePooledJndiBindingDUnitTest}} is current in package
> org.apache.geode.connectors.jdbc with @Category(\{JDBCConnectorTest.class})
> It should be in the package:
> org.apache.geode.management.internal.cli.commands with
> @Category(GfshTest.class)
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (GEODE-6707) gfsh export logs does not export rolled over GC logs
[ https://issues.apache.org/jira/browse/GEODE-6707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dick Cavender updated GEODE-6707: - Fix Version/s: 1.10.0 > gfsh export logs does not export rolled over GC logs > - > > Key: GEODE-6707 > URL: https://issues.apache.org/jira/browse/GEODE-6707 > Project: Geode > Issue Type: Improvement > Components: gfsh >Reporter: Srikanth Manvi >Assignee: Srikanth Manvi >Priority: Minor > Fix For: 1.10.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > If GC logs are configured to land in the same directory as Geode server logs > then the current GC log is exported when we run gfsh>export logs. However if > the rolled over GC logs are not exported. > This happens because the rolled over GC logs are of the form server_gc.log.16 > and gfsh export command logs for files ending with *.log however GC log > rolling causes the files to end with a file number. > > Note: If GC logs are written a directory other than where server logs end > up, then even the latest GC log doesn't get exported. GEODE-6706 talks about > that. > -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (GEODE-6719) App servers using custom DEFAULT diskstores should be able to restart
[ https://issues.apache.org/jira/browse/GEODE-6719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dick Cavender updated GEODE-6719: - Fix Version/s: 1.10.0 > App servers using custom DEFAULT diskstores should be able to restart > - > > Key: GEODE-6719 > URL: https://issues.apache.org/jira/browse/GEODE-6719 > Project: Geode > Issue Type: Bug > Components: http session >Reporter: nabarun >Priority: Major > Fix For: 1.10.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Issue: > # Start servers with DEFAULT diskstores with custom directory location other > than '.' and do not set the diskstore in the region attributes tag in the > cache xml. Since it is named DEFAULT, it should automatically link itself to > the region. > # Start the app server > # Stop the app server > # Start the app server. > # This causes a failure as app server requests it create the default > diskstore at . but the default diskstore was already created at the custom > location. > Solution: > * If the existing region and the requested region both use the default disk > store then the existing diskstore properties with take precedence over the > requested ones. > * The requested disktore properties will be ignored if there is a default > diskstore already present. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (GEODE-6766) Add reaper job for benchmark instances
[ https://issues.apache.org/jira/browse/GEODE-6766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dick Cavender updated GEODE-6766: - Fix Version/s: 1.10.0 > Add reaper job for benchmark instances > -- > > Key: GEODE-6766 > URL: https://issues.apache.org/jira/browse/GEODE-6766 > Project: Geode > Issue Type: Improvement > Components: ci >Reporter: Sean Goller >Priority: Major > Fix For: 1.10.0 > > Time Spent: 50m > Remaining Estimate: 0h > > Add a job that runs four times a day, which checks for free-roaming benchmark > clusters and destroys them. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (GEODE-6752) CI: A passing build ID, in addition to PassingRef, would be useful
[ https://issues.apache.org/jira/browse/GEODE-6752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dick Cavender updated GEODE-6752: - Fix Version/s: 1.10.0 > CI: A passing build ID, in addition to PassingRef, would be useful > -- > > Key: GEODE-6752 > URL: https://issues.apache.org/jira/browse/GEODE-6752 > Project: Geode > Issue Type: Improvement >Reporter: Patrick Rhomberg >Assignee: Patrick Rhomberg >Priority: Major > Fix For: 1.10.0 > > Time Spent: 1h > Remaining Estimate: 0h > > During development, it is useful to have the build ID rather than just the > SHA of a passing build, for investigating differences between the CI passing > build's artifacts against a local build at the same SHA. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (GEODE-6772) create index sometimes will create the index but failed to update the cluster configuration.
[ https://issues.apache.org/jira/browse/GEODE-6772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dick Cavender updated GEODE-6772: - Fix Version/s: 1.10.0 > create index sometimes will create the index but failed to update the cluster > configuration. > > > Key: GEODE-6772 > URL: https://issues.apache.org/jira/browse/GEODE-6772 > Project: Geode > Issue Type: Bug > Components: gfsh, management >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Fix For: 1.10.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Scenario: > 1. start a server (server-1) in group1: start server --name=server-1 > --group=group1 > 2. start another server-2 with no group: start server --name=server-2 > 3. create a regionA in group1: create region --name=regionA --group=group1 > --type=REPLICATE > 4. create an index on regionA: create index --region=regionA --name=index1 > > observe that command will try to create index on both servers, but failed on > server-2, since server-2 has no regionA, but the failure caused the cluster > configuration not being updated. > Proposal: > when create index, the region already should determine what members this > index needs to be created on, there should be no need for user to specify a > group. We should ignore "group" when cluster configuration is enabled. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (GEODE-6785) StoppableCountDownLatch reads a system property every time the constructor is called
[ https://issues.apache.org/jira/browse/GEODE-6785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dick Cavender updated GEODE-6785: - Fix Version/s: 1.10.0 > StoppableCountDownLatch reads a system property every time the constructor is > called > > > Key: GEODE-6785 > URL: https://issues.apache.org/jira/browse/GEODE-6785 > Project: Geode > Issue Type: Improvement > Components: core >Reporter: Darrel Schneider >Assignee: Mario Ivanac >Priority: Major > Labels: performance, pull-request-available > Fix For: 1.10.0 > > Time Spent: 50m > Remaining Estimate: 0h > > The public constructor on StoppableCountDownLatch reads a system property > each time. > This is a synchronized operation and every time we wait for a response from a > peer we create one (In ReplyProcessor21). We don't expect this system > property to change on a running jvm so we could read it once and cache the > result to improve performance. > The expression that reads the system property is: > MILLISECONDS.toNanos(Long.getLong(RETRY_TIME_MILLIS_PROPERTY, > RETRY_TIME_MILLIS_DEFAULT)) -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (GEODE-6857) Refactor client function timeout
[ https://issues.apache.org/jira/browse/GEODE-6857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dick Cavender updated GEODE-6857: - Fix Version/s: 1.10.0 > Refactor client function timeout > > > Key: GEODE-6857 > URL: https://issues.apache.org/jira/browse/GEODE-6857 > Project: Geode > Issue Type: Improvement > Components: functions >Reporter: Jacob S. Barrett >Assignee: Jacob S. Barrett >Priority: Major > Fix For: 1.10.0 > > Time Spent: 2.5h > Remaining Estimate: 0h > > Currently function timeout is stored in the ConnectionImpl. ConnectionImpl > checks for specific function operations when executing operations and then > adjust the timeout. Move all this logic to the function operations and inject > the timeout from owning object. This should properly encapsulate the special > behavior of function timeout as well as make testing easier. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (GEODE-7004) Optimize ResourcePermission constructor
[
https://issues.apache.org/jira/browse/GEODE-7004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dick Cavender updated GEODE-7004:
-
Fix Version/s: 1.10.0
> Optimize ResourcePermission constructor
>
>
> Key: GEODE-7004
> URL: https://issues.apache.org/jira/browse/GEODE-7004
> Project: Geode
> Issue Type: Improvement
> Components: security
>Reporter: Kamilla Aslami
>Assignee: Kamilla Aslami
>Priority: Major
> Labels: performance
> Fix For: 1.10.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> PartitionedPutBenchmark with Security Manager enabled shows a performance
> degradation:
> {noformat}
> org.apache.geode.benchmark.tests.PartitionedPutBenchmark
> average ops/second Baseline:313077.71 Test:303114.88
> Difference: -3.2%
>ops/second standard error Baseline: 714.84 Test: 511.86
> Difference: -28.4%
>ops/second standard deviation Baseline: 12360.75 Test: 8850.96
> Difference: -28.4%
> YS 99th percentile latency Baseline: 2901.00 Test: 2802.00
> Difference: -3.4%
> median latency Baseline: 1586175.00 Test: 1613823.00
> Difference: +1.7%
> 90th percentile latency Baseline: 2289663.00 Test: 2303999.00
> Difference: +0.6%
> 99th percentile latency Baseline: 3213311.00 Test: 3289087.00
> Difference: +2.4%
>99.9th percentile latency Baseline: 72220671.00 Test: 61636607.00
> Difference: -14.7%
> average latency Baseline: 1838420.24 Test: 1898668.38
> Difference: +3.3%
> latency standard deviation Baseline: 3840098.38 Test: 3827737.37
> Difference: -0.3%
> latency standard error Baseline: 396.30 Test: 401.43
> Difference: +1.3%
> {noformat}
> In stats, we noticed a higher CPU utilization and less puts.
>
> When Security Manager is enabled, every put operation calls
> IntegratedSecurityService.authorize method, which creates new
> ResourcePermission object. Every execution of ResourcePermission constructor
> takes 5 ms. With the optimization, ResourcePermission constructor execution
> takes less than 0.1 ms.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (GEODE-7027) build-google-windows-geode-builder frequently fails to build because of rsync location instability
[ https://issues.apache.org/jira/browse/GEODE-7027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dick Cavender updated GEODE-7027: - Fix Version/s: 1.10.0 > build-google-windows-geode-builder frequently fails to build because of rsync > location instability > -- > > Key: GEODE-7027 > URL: https://issues.apache.org/jira/browse/GEODE-7027 > Project: Geode > Issue Type: Bug > Components: ci >Reporter: Sean Goller >Assignee: Sean Goller >Priority: Major > Fix For: 1.10.0 > > Time Spent: 20m > Remaining Estimate: 0h > > The build-google-windows-geode-builder job frequently fails because of > instability surrounding fetching rsync via chocolatey. Get rsync a different > way to resolve this. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (GEODE-7214) CI Failure: org.apache.geode.distributed.LocatorUDPSecurityDUnitTest.testConcurrentLocatorStartup
[ https://issues.apache.org/jira/browse/GEODE-7214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dick Cavender updated GEODE-7214: - Affects Version/s: 1.10.0 > CI Failure: > org.apache.geode.distributed.LocatorUDPSecurityDUnitTest.testConcurrentLocatorStartup > - > > Key: GEODE-7214 > URL: https://issues.apache.org/jira/browse/GEODE-7214 > Project: Geode > Issue Type: Bug >Affects Versions: 1.10.0 >Reporter: Dick Cavender >Priority: Major > > ```> Task :geode-core:distributedTest > org.apache.geode.distributed.LocatorUDPSecurityDUnitTest > > testConcurrentLocatorStartup 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 2634 > [fatal 2019/09/17 17:47:57.694 GMT > tid=493] Uncaught exception in thread Thread[Geode Failure Detection thread > 2,5,RMI Runtime] > java.util.concurrent.RejectedExecutionException: Task > org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor$$Lambda$184/76964693@20a2fafd > rejected from java.util.concurrent.ThreadPoolExecutor@2e651099[Shutting > down, pool size = 2, active threads = 2, queued tasks = 0, completed tasks = > 2] > at > java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2063) > at > java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:830) > at > java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1379) > at > org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.checkIfAvailable(GMSHealthMonitor.java:1286) > at > org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.processMessage(GMSHealthMonitor.java:1187) > at > org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.sendSuspectRequest(GMSHealthMonitor.java:1448) > at > org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.initiateSuspicion(GMSHealthMonitor.java:469) > at > org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.lambda$checkMember$0(GMSHealthMonitor.java:453) > 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)``` -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (GEODE-7214) CI Failure: org.apache.geode.distributed.LocatorUDPSecurityDUnitTest.testConcurrentLocatorStartup
Dick Cavender created GEODE-7214: Summary: CI Failure: org.apache.geode.distributed.LocatorUDPSecurityDUnitTest.testConcurrentLocatorStartup Key: GEODE-7214 URL: https://issues.apache.org/jira/browse/GEODE-7214 Project: Geode Issue Type: Bug Reporter: Dick Cavender ```> Task :geode-core:distributedTest org.apache.geode.distributed.LocatorUDPSecurityDUnitTest > testConcurrentLocatorStartup 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 2634 [fatal 2019/09/17 17:47:57.694 GMT tid=493] Uncaught exception in thread Thread[Geode Failure Detection thread 2,5,RMI Runtime] java.util.concurrent.RejectedExecutionException: Task org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor$$Lambda$184/76964693@20a2fafd rejected from java.util.concurrent.ThreadPoolExecutor@2e651099[Shutting down, pool size = 2, active threads = 2, queued tasks = 0, completed tasks = 2] at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2063) at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:830) at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1379) at org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.checkIfAvailable(GMSHealthMonitor.java:1286) at org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.processMessage(GMSHealthMonitor.java:1187) at org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.sendSuspectRequest(GMSHealthMonitor.java:1448) at org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.initiateSuspicion(GMSHealthMonitor.java:469) at org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.lambda$checkMember$0(GMSHealthMonitor.java:453) 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)``` -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (GEODE-7214) CI Failure: org.apache.geode.distributed.LocatorUDPSecurityDUnitTest.testConcurrentLocatorStartup
[ https://issues.apache.org/jira/browse/GEODE-7214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dick Cavender updated GEODE-7214: - Description: > Task :geode-core:distributedTest org.apache.geode.distributed.LocatorUDPSecurityDUnitTest > testConcurrentLocatorStartup 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 2634 [fatal 2019/09/17 17:47:57.694 GMT tid=493] Uncaught exception in thread Thread[Geode Failure Detection thread 2,5,RMI Runtime] java.util.concurrent.RejectedExecutionException: Task org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor$$Lambda$184/76964693@20a2fafd rejected from java.util.concurrent.ThreadPoolExecutor@2e651099[Shutting down, pool size = 2, active threads = 2, queued tasks = 0, completed tasks = 2] at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2063) at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:830) at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1379) at org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.checkIfAvailable(GMSHealthMonitor.java:1286) at org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.processMessage(GMSHealthMonitor.java:1187) at org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.sendSuspectRequest(GMSHealthMonitor.java:1448) at org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.initiateSuspicion(GMSHealthMonitor.java:469) at org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.lambda$checkMember$0(GMSHealthMonitor.java:453) 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) was: ```> Task :geode-core:distributedTest org.apache.geode.distributed.LocatorUDPSecurityDUnitTest > testConcurrentLocatorStartup 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 2634 [fatal 2019/09/17 17:47:57.694 GMT tid=493] Uncaught exception in thread Thread[Geode Failure Detection thread 2,5,RMI Runtime] java.util.concurrent.RejectedExecutionException: Task org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor$$Lambda$184/76964693@20a2fafd rejected from java.util.concurrent.ThreadPoolExecutor@2e651099[Shutting down, pool size = 2, active threads = 2, queued tasks = 0, completed tasks = 2] at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2063) at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:830) at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1379) at org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.checkIfAvailable(GMSHealthMonitor.java:1286) at org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.processMessage(GMSHealthMonitor.java:1187) at org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.sendSuspectRequest(GMSHealthMonitor.java:1448) at org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.initiateSuspicion(GMSHealthMonitor.java:469) at org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.lambda$checkMember$0(GMSHealthMonitor.java:453) 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)``` > CI Failure: > org.apache.geode.distributed.LocatorUDPSecurityDUnitTest.testConcurrentLocatorStartup > - > > Key: GEODE-7214 > URL: https://issues.apache.org/jira/browse/GEODE-7214 > Project: Geode > Issue Type: Bug >Affects Versions: 1.10.0 >Reporter: Dick Cavender >Priority: Major > > > Task :geode-core:distributedTest > org.apache.geode.distributed.LocatorUDPSecurityDUnitTest > > testConcurrentLocatorStartup FAILED > java.lang.AssertionError: Suspicious strings were written to
[jira] [Updated] (GEODE-6751) CI failure: AcceptanceTestOpenJDK8 ConnectCommandAcceptanceTest.useCurrentGfshToConnectToOlderLocator failure
[ https://issues.apache.org/jira/browse/GEODE-6751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dick Cavender updated GEODE-6751: - Fix Version/s: (was: 1.10.0) 1.11.0 > CI failure: AcceptanceTestOpenJDK8 > ConnectCommandAcceptanceTest.useCurrentGfshToConnectToOlderLocator failure > - > > Key: GEODE-6751 > URL: https://issues.apache.org/jira/browse/GEODE-6751 > Project: Geode > Issue Type: Bug > Components: management >Reporter: Scott Jewell >Priority: Major > Fix For: 1.11.0 > > > Assertion failure in > ConnectCommandAcceptanceTest.useCurrentGfshToConnectToOlderLocator > Appears to be a new bug > org.apache.geode.management.internal.cli.commands.ConnectCommandAcceptanceTest > > useCurrentGfshToConnectToOlderLocator FAILED > java.lang.AssertionError: > Expecting: > <" > (1) Executing - connect > Connecting to Locator at [host=localhost, port=10334] .. > Exception caused JMX Manager startup to fail because: 'HTTP service > failed to start' > "> > to contain: > <"Cannot use a"> > at > org.apache.geode.management.internal.cli.commands.ConnectCommandAcceptanceTest.useCurrentGfshToConnectToOlderLocator(ConnectCommandAcceptanceTest.java:50) > 60 tests completed, 1 failed > =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > [*http://files.apachegeode-ci.info/builds/apache-develop-main/1.10.0-SNAPSHOT.0258/test-results/acceptanceTest/1557290414/*] > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Test report artifacts from this job are available at: > [*http://files.apachegeode-ci.info/builds/apache-develop-main/1.10.0-SNAPSHOT.0258/test-artifacts/1557290414/acceptancetestfiles-OpenJDK8-1.10.0-SNAPSHOT.0258.tgz*] > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-4240) CI failure: DeprecatedCacheServerLauncherIntegrationTest fails sporadically with execution timeout
[
https://issues.apache.org/jira/browse/GEODE-4240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dick Cavender updated GEODE-4240:
-
Fix Version/s: (was: 1.10.0)
1.11.0
> CI failure: DeprecatedCacheServerLauncherIntegrationTest fails sporadically
> with execution timeout
> --
>
> Key: GEODE-4240
> URL: https://issues.apache.org/jira/browse/GEODE-4240
> Project: Geode
> Issue Type: Bug
>Reporter: Patrick Rhomberg
>Priority: Major
> Labels: flaky, linux, windows
> Fix For: 1.11.0
>
> Attachments: DeprecatedCacheServerLauncherIntegrationTest.log
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> While possibly unrelated, it is worth noting other recent failures due to
> startup timeouts.
> ([GEODE-4236](https://issues.apache.org/jira/browse/GEODE-4236) comes to
> mind.)
> I have recently seen a failure in this test timing out with the following
> stacktrace:
> {noformat}
> java.lang.AssertionError: Timed out waiting for output "CacheServer pid: \d+
> status: running" after 12 ms. Output:
> Starting CacheServer with pid: 0
> at org.junit.Assert.fail(Assert.java:88)
> at
> org.apache.geode.test.process.ProcessWrapper.waitForOutputToMatch(ProcessWrapper.java:222)
> at
> org.apache.geode.internal.cache.DeprecatedCacheServerLauncherIntegrationTest.execAndValidate(DeprecatedCacheServerLauncherIntegrationTest.java:437)
> at
> org.apache.geode.internal.cache.DeprecatedCacheServerLauncherIntegrationTest.testStartStatusStop(DeprecatedCacheServerLauncherIntegrationTest.java:164)
> 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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
> 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.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> at
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
> at
> org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDisp
[jira] [Updated] (GEODE-3780) suspected member is never watched again after passing final check
[ https://issues.apache.org/jira/browse/GEODE-3780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dick Cavender updated GEODE-3780: - Fix Version/s: (was: 1.10.0) 1.11.0 > suspected member is never watched again after passing final check > - > > Key: GEODE-3780 > URL: https://issues.apache.org/jira/browse/GEODE-3780 > Project: Geode > Issue Type: Bug > Components: membership >Reporter: Bruce J Schuchardt >Assignee: Bruce J Schuchardt >Priority: Major > Labels: pull-request-available > Fix For: 1.11.0 > > Time Spent: 2.5h > Remaining Estimate: 0h > > In a network-down test we saw a node on the losing side of the network > partition perform final checks on members on the winning side. One of the > final checks mysteriously succeeded > [info 2017/09/17 12:24:45.552 PDT > gemfire1_rs-FullRegression-2017-09-15-21-00-35-client-10_8941 Detection thread 4> tid=0x128] Final check failed but detected recent message > traffic for suspect member > 10.32.109.252(gemfire3_rs-FullRegression-2017-09-15-21-00-35-client-16_6135:6135):1026 > [info 2017/09/17 12:24:45.552 PDT > gemfire1_rs-FullRegression-2017-09-15-21-00-35-client-10_8941 Detection thread 4> tid=0x128] Final check passed for suspect member > 10.32.109.252(gemfire3_rs-FullRegression-2017-09-15-21-00-35-client-16_6135:6135):1026 > After this the suspected member was never checked again and the losing side > failed to shut down. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-6779) Create disk-store command should only return when DistributedSystemMXBean reflects creation status
[
https://issues.apache.org/jira/browse/GEODE-6779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dick Cavender updated GEODE-6779:
-
Fix Version/s: (was: 1.10.0)
1.11.0
> Create disk-store command should only return when DistributedSystemMXBean
> reflects creation status
> --
>
> Key: GEODE-6779
> URL: https://issues.apache.org/jira/browse/GEODE-6779
> Project: Geode
> Issue Type: Improvement
> Components: gfsh
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
> Fix For: 1.11.0
>
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> Once fixed, we can remove
> {{MemberVM.waitUntilDiskStoreIsReadyOnExactlyThisManyServers}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-6183) CI Failure: LocatorLauncherRemoteFileIntegrationTest.startDeletesStaleControlFiles failed with ConditionTimeoutException
[ https://issues.apache.org/jira/browse/GEODE-6183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dick Cavender updated GEODE-6183: - Fix Version/s: (was: 1.10.0) 1.11.0 > CI Failure: > LocatorLauncherRemoteFileIntegrationTest.startDeletesStaleControlFiles failed > with ConditionTimeoutException > > > Key: GEODE-6183 > URL: https://issues.apache.org/jira/browse/GEODE-6183 > Project: Geode > Issue Type: Bug > Components: ci, gfsh >Reporter: Eric Shu >Assignee: Kirk Lund >Priority: Major > Fix For: 1.11.0 > > Time Spent: 5.5h > Remaining Estimate: 0h > > Test failed in > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/IntegrationTestOpenJDK8/builds/223 > org.apache.geode.distributed.LocatorLauncherRemoteFileIntegrationTest > > startDeletesStaleControlFiles FAILED > org.awaitility.core.ConditionTimeoutException: Assertion condition > defined as a lambda expression in > org.apache.geode.distributed.LocatorLauncherRemoteIntegrationTestCase that > uses org.apache.geode.distributed.LocatorLauncher expected:<[online]> but > was:<[not responding]> within 300 seconds. > Caused by: > org.junit.ComparisonFailure: expected:<[online]> but was:<[not > responding]> -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-1730) Cleanup SmHelper, SharedLibrary, PureJavaMode classes
[ https://issues.apache.org/jira/browse/GEODE-1730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dick Cavender closed GEODE-1730. > Cleanup SmHelper, SharedLibrary, PureJavaMode classes > - > > Key: GEODE-1730 > URL: https://issues.apache.org/jira/browse/GEODE-1730 > Project: Geode > Issue Type: Improvement > Components: general >Reporter: Kirk Lund >Priority: Minor > Labels: starter > Fix For: 1.10.0 > > > These classes are for the GemFire native code which is not in Geode. There > are a couple of methods still used on these classes such as is64bit() which > could be moved to another class such as SystemUtils. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-6634) Fix parallel option for repeatTest
[
https://issues.apache.org/jira/browse/GEODE-6634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dick Cavender closed GEODE-6634.
> Fix parallel option for repeatTest
> --
>
> Key: GEODE-6634
> URL: https://issues.apache.org/jira/browse/GEODE-6634
> Project: Geode
> Issue Type: Bug
> Components: build
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
> Fix For: 1.10.0
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> Currently both {{--parallel}} and {{--no-parallel}} options are being used
> for stress tests.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (GEODE-6523) Disable new REST and Java API behind feature flag
[ https://issues.apache.org/jira/browse/GEODE-6523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dick Cavender closed GEODE-6523. > Disable new REST and Java API behind feature flag > - > > Key: GEODE-6523 > URL: https://issues.apache.org/jira/browse/GEODE-6523 > Project: Geode > Issue Type: Improvement > Components: management >Reporter: Peter Tran >Priority: Major > Fix For: 1.10.0 > > Time Spent: 1.5h > Remaining Estimate: 0h > > Discuss: Do we want our new functionality to be disabled by default until > such time as we are happy to make it publicly available? Other features - > e.g. protobuf currently do this. > If we do this, please use a feature-flag system property of the form: > `geode.feature-cluster-management-service` for consistency with other feature > flags. > * consider tests > * GFSH start option to switch it on > * Augment Experimental (don't turn off experimental with addition) > * What happens with Experimental later, leave it on until we are solid on the > External/public API. > * Feature flag = MVP adding value, Experimental = public API is solid > there is one flag to control this feature as Java Runtime properties "--J-D": > - enable-experimental-cluster-management-service: for features, which is > just an experimental, just want to get some feedback from early birds. > ### Why > We want users to not have access to Experimental API by default because it > could be in a state that is insecure/incomplete/could cause corruption of a > system. We need to turn this off by default so that users can opt into this > functionality. > ### Acceptance Criteria > ```gherkin > Scenario: System doesn't see this flag > Given geode is unpacked in a directory > When the system cannot find a flag of > 'enable-experimental-cluster-management-service' in Java Runtime properties. > Then the REST API v2 will not be available to the user on any port of the > locator > AND a info level log would be added to locator log: "CMS is turned off , > because value the experimental flag: > enable-experimental-cluster-management-service is false." > ``` > ```gherkin > Scenario: User default false for opt-in on experimental > Given the user does not change this flag > 'enable-experimental-cluster-management-service' and its default value. > When the user starts a locator > Then the REST API v2 will not be available to the user on any port of the > locator > AND a info level log would be added to locator log: "CMS is turned off , > because value the experimental flag: > enable-experimental-cluster-management-service is false." > ``` > ```gherkin > Scenario: User default incorrectly specified flag value > Given geode is unpacked in a directory > When the user specifies an incorrect value for this flag: > 'enable-experimental-cluster-management-service' by Java Runtime properties > "--J-D" > Then the REST API v2 will not be available to the user on any port of the > locator > AND a info level log would be added to locator log: "CMS is turned off , > because value the experimental flag: > enable-experimental-cluster-management-service is false." > ``` > ```gherkin > Scenario: User opts into the experimental flag > Given geode is unpacked in a directory > When the user enables this flag: > 'enable-experimental-cluster-management-service' by Java Runtime properties > "--J-D" > Then the REST API v2 will be available to the user at the standard port of > 7070 or whatever port the user has specified. > AND a info level log would be added to locator log: "CMS is turned on , > because value the experimental flag: > enable-experimental-cluster-management-service is true." > ``` > **Notes:** -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-6791) Wrong file should be removed from repository
[ https://issues.apache.org/jira/browse/GEODE-6791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dick Cavender closed GEODE-6791. > Wrong file should be removed from repository > > > Key: GEODE-6791 > URL: https://issues.apache.org/jira/browse/GEODE-6791 > Project: Geode > Issue Type: Bug >Reporter: Alberto Bustamante Reyes >Assignee: Alberto Bustamante Reyes >Priority: Trivial > Labels: pull-request-available > Fix For: 1.10.0 > > Time Spent: 20m > Remaining Estimate: 0h > > In geode-core/src/main/java/org/apache/geode/internal/cache/ there is a wrong > file, probably it was not removed after a merge and it was added to the repo: > "HasDiskRegion.java~d2263ebc2... Create HasDiskRegion interface" > HasDiskRegion.java was created in GEODE-3870 > The wrong file was introduced one month later by GEODE-3622 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-6756) Allow key/value contraints to be specified for region creation in V2 Management API
[ https://issues.apache.org/jira/browse/GEODE-6756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dick Cavender closed GEODE-6756. > Allow key/value contraints to be specified for region creation in V2 > Management API > --- > > Key: GEODE-6756 > URL: https://issues.apache.org/jira/browse/GEODE-6756 > Project: Geode > Issue Type: New Feature > Components: management >Reporter: Jinmei Liao >Priority: Major > Fix For: 1.10.0 > > Time Spent: 1h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-6551) Multiple Executions of RegionAlterFunction Leaves Partition Region Inconsistent
[
https://issues.apache.org/jira/browse/GEODE-6551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dick Cavender closed GEODE-6551.
> Multiple Executions of RegionAlterFunction Leaves Partition Region
> Inconsistent
> ---
>
> Key: GEODE-6551
> URL: https://issues.apache.org/jira/browse/GEODE-6551
> Project: Geode
> Issue Type: Bug
> Components: configuration, gfsh, wan
>Reporter: Juan Ramos
>Assignee: Juan Ramos
>Priority: Major
> Fix For: 1.10.0
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> When trying to assign a non-persistent parallel {{gateway-sender}} /
> {{async-event-queue}} to a persistent partitioned region through {{gfsh}},
> the actual region is left inconsistent in the {{cluster configuration
> service}} if the internal function is executed more than once.
> The problem is that the {{gateway-sender}} / {{async-event-queue}} is added
> to the internal list too early within the execution lifecycle and, if the
> actual addition fails afterwards, the internal list is never reverted to its
> original state. This invalid configuration is persisted into the cluster
> configuration service afterwards (for the second, "successful execution"), so
> the subsequent restart of the servers will miserably fail.
> The following set of steps reproduces the problem for a {{gateway-sender}},
> but the logic is exactly the same for an {{async-event-queue}}:
> {noformat}
> gfsh -e "start locator --name=locator --port=10101"
> gfsh -e "start server --name=server --server-port=40404
> --locators=localhost[10101]"
> gfsh -e "connect --locator=localhost[10101]" -e "create disk-store
> --name=diskStore --dir=diskStore"
> gfsh -e "connect --locator=localhost[10101]" -e "create region
> --name=testRegion --type=PARTITION_PERSISTENT --disk-store=diskStore"
> gfsh -e "connect --locator=localhost[10101]" -e "create gateway-sender
> --id=gateway --parallel=true --remote-distributed-system-id=2
> --enable-persistence=false"
> # First Execution Fails
> gfsh -e "connect --locator=localhost[10101]" -e "alter region
> --name=testRegion --gateway-sender-id=gateway"
> Member | Status | Message
> -- | -- |
> ---
> server | ERROR |
> org.apache.geode.internal.cache.wan.GatewaySenderException: Non persistent
> gateway sender gateway can not be attached to persistent region /testRegion
> # Second Execution Succeeds
> gfsh -e "connect --locator=localhost[10101]" -e "alter region
> --name=testRegion --gateway-sender-id=gateway"
> Member | Status | Message
> -- | -- | -
> server | OK | Region testRegion altered
> gfsh -e "connect --locator=localhost[10101]" -e "stop server --name=server"
> gfsh -e "start server --name=server --server-port=40404
> --locators=localhost[10101]"
> The Cache Server process terminated unexpectedly with exit status 1.
> Please refer to the log file in /server for full details.
> Exception in thread "main"
> org.apache.geode.internal.cache.wan.GatewaySenderException: Non persistent
> gateway sender gateway can not be attached to persistent region /testRegion
> at
> org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderQueue.addShadowPartitionedRegionForUserPR(ParallelGatewaySenderQueue.java:454)
> # The log shows that the cluster configuration receiged is invalid:
> [info 2019/03/21 11:52:57.606 GMT tid=0x1] Received cluster
> configuration from the locator
> [info 2019/03/21 11:52:57.638 GMT tid=0x1]
> ***
> Configuration for 'cluster'
> Jar files to deployed
>
> http://geode.apache.org/schema/cache";
> xmlns:jdbc="http://geode.apache.org/schema/jdbc";
> xmlns:lucene="http://geode.apache.org/schema/lucene";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; version="1.0"
> xsi:schemaLocation="http://geode.apache.org/schema/lucene
> http://geode.apache.org/schema/lucene/lucene-1.0.xsd
> http://geode.apache.org/schema/jdbc
> http://geode.apache.org/schema/jdbc/jdbc-1.0.xsd
> http://geode.apache.org/schema/cache
> http://geode.apache.org/schema/cache/cache-1.0.xsd";>
> enable-persistence="false" id="gateway" manual-start="false" parallel="true"
> remote-distributed-system-id="2"/>
> compaction-threshold="50" disk-usage-critical-percentage="99"
> disk-usage-warning-percentage="90" max-oplog-size="1024" name="diskStore"
> queue-size="0" time-interval="1000" write-buffer-size="32768">
>
> diskStore
>
>
>
> disk-store-name="diskStore" gateway-sender-ids="gateway"/>
>
>
> {n
[jira] [Closed] (GEODE-6834) PartitionedRegionStats counters should be 64 bit to prevent wrap around
[ https://issues.apache.org/jira/browse/GEODE-6834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dick Cavender closed GEODE-6834. > PartitionedRegionStats counters should be 64 bit to prevent wrap around > --- > > Key: GEODE-6834 > URL: https://issues.apache.org/jira/browse/GEODE-6834 > Project: Geode > Issue Type: Improvement > Components: core >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Fix For: 1.10.0 > > Time Spent: 50m > Remaining Estimate: 0h > > I was looking at getsCompleted on PartitionedRegionStats when the gets are > done in a function and they happen so fast that the 32-bit counter wraps > around. > Other stats on PartitionedRegionStats could have the same issue. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-6697) Reduce lock contention on system property access in InternalDistributedMember.SHOW_NETMEMBER
[ https://issues.apache.org/jira/browse/GEODE-6697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dick Cavender closed GEODE-6697. > Reduce lock contention on system property access in > InternalDistributedMember.SHOW_NETMEMBER > > > Key: GEODE-6697 > URL: https://issues.apache.org/jira/browse/GEODE-6697 > Project: Geode > Issue Type: Improvement >Reporter: Jacob Barrett >Priority: Major > Fix For: 1.10.0 > > Time Spent: 20m > Remaining Estimate: 0h > > System properties are held in a HashTable, which is synchronized. For values > that do not change at runtime, like system properties, it is best to fetch > them into a static variable. Every operation was synchronizing on access to > this property. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-6376) PersistentRecoveryOrderDUnitTest > testCrashDuringPreparePersistentId FAILED
[
https://issues.apache.org/jira/browse/GEODE-6376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dick Cavender closed GEODE-6376.
> PersistentRecoveryOrderDUnitTest > testCrashDuringPreparePersistentId FAILED
>
>
> Key: GEODE-6376
> URL: https://issues.apache.org/jira/browse/GEODE-6376
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Mark Hanson
>Assignee: Kirk Lund
>Priority: Major
> Labels: CI
> Fix For: 1.10.0
>
>
> Failure Link
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/373
> Log Archives:
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.9.0-SNAPSHOT.0412/test-results/distributedTest/1549403523/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.9.0-SNAPSHOT.0412/test-artifacts/1549403523/distributedtestfiles-OpenJDK11-1.9.0-SNAPSHOT.0412.tgz
> Stack Trace:
> {code}
> java.lang.RuntimeException: java.lang.IllegalStateException: Disk store
> PersistentRecoveryOrderDUnitTest_testCrashDuringPreparePersistentIdRegion not
> found
> at
> org.apache.geode.internal.cache.persistence.PersistentReplicatedTestBase._createPersistentRegion(PersistentReplicatedTestBase.java:194)
> at
> org.apache.geode.internal.cache.persistence.PersistentReplicatedTestBase.createPersistentRegion(PersistentReplicatedTestBase.java:180)
> at
> org.apache.geode.internal.cache.persistence.PersistentRecoveryOrderDUnitTest.testCrashDuringPreparePersistentId(PersistentRecoveryOrderDUnitTest.java:1325)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
> at
> org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:66)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
> org.gradle
[jira] [Closed] (GEODE-7037) MAX_QUERY_EXECUTION_TIME is incorrectly shown in docs
[ https://issues.apache.org/jira/browse/GEODE-7037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dick Cavender closed GEODE-7037. > MAX_QUERY_EXECUTION_TIME is incorrectly shown in docs > - > > Key: GEODE-7037 > URL: https://issues.apache.org/jira/browse/GEODE-7037 > Project: Geode > Issue Type: Bug > Components: docs >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Minor > Fix For: 1.10.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Link: > [https://geode.apache.org/docs/guide/19/developing/query_additional/query_timeout.html] > Text: > _"Timeouts for Long-Running Queries > GemFire can monitor and throw an exception when a query runs longer than a > configured amount of time. This feature is enabled by setting the > critical-heap-percentage attribute which detects that the JVM has too little > heap memory. > The default query timeout is five hours. Set a different amount of time, in > milliseconds, by specifying the system variable > *gemfire.cache.MAX_QUERY_EXECUTION_TIME*. A value of -1 explicitly disables > the timeout. > When enabled, a query that runs longer than the configured timeout will be > cancelled such that it does not finish, and GemFire throws a > QueryExecutionTimeoutException."_ > The above is wrong. The parameter is case sensitive and it should be: > *gemfire.Cache.MAX_QUERY_EXECUTION_TIME* with an upper case C. > This was tested and checked in the code: > _public static int MAX_QUERY_EXECUTION_TIME = > Integer.getInteger(DistributionConfig.GEMFIRE_PREFIX + > "Cache.MAX_QUERY_EXECUTION_TIME", -1); > _ > So using *gemfire.cache.MAX_QUERY_EXECUTION_TIME* will not change the time > out. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-6796) Improve error message when gfsh connect fails
[ https://issues.apache.org/jira/browse/GEODE-6796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dick Cavender closed GEODE-6796. > Improve error message when gfsh connect fails > - > > Key: GEODE-6796 > URL: https://issues.apache.org/jira/browse/GEODE-6796 > Project: Geode > Issue Type: Improvement > Components: gfsh >Reporter: Peter Tran >Assignee: Jack Weissburg >Priority: Major > Fix For: 1.10.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > Currently when gfsh connect fails we see > [code] > gfsh -e "connect --locator=l192.168.99.1[52326]" > Connecting to Locator at [host=l192.168.99.1, port=52326] .. > l192.168.99.1: nodename nor servname provided, or not known > [/code] > The language "nor servname" can be more helpful. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-6565) DistributedSystem.connect may create and configure IntegratedSecurityService which never gets cleaned up if Cache is never created
[ https://issues.apache.org/jira/browse/GEODE-6565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dick Cavender closed GEODE-6565. > DistributedSystem.connect may create and configure IntegratedSecurityService > which never gets cleaned up if Cache is never created > -- > > Key: GEODE-6565 > URL: https://issues.apache.org/jira/browse/GEODE-6565 > Project: Geode > Issue Type: Bug > Components: security >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Fix For: 1.10.0 > > Time Spent: 20m > Remaining Estimate: 0h > > If a DistributedSystem connection configured for integrated security is > created but a Cache is never created then the > IntegratedSecurityService.close() is never invoked. This leaves a Shiro > ThreadLocal in existence that causes the subsequent DistributedSystem to be > configured for integrated security even if no security properties are > specified. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-6831) Versioning of JAR Files doc is wrong
[ https://issues.apache.org/jira/browse/GEODE-6831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dick Cavender closed GEODE-6831. > Versioning of JAR Files doc is wrong > - > > Key: GEODE-6831 > URL: https://issues.apache.org/jira/browse/GEODE-6831 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: YuJue Li >Assignee: Dave Barnes >Priority: Major > Fix For: 1.10.0 > > Time Spent: 20m > Remaining Estimate: 0h > > [https://geode.apache.org/docs/guide/19/configuring/cluster_config/deploying_application_jars.html] > > > This document has such a paragraph: > > Versioning of JAR Files > > When you deploy JAR files to a cluster or member group, the JAR file is > modified to indicate version information in its name. Each JAR filename is > prefixed with|vf.gf#|and contains a version number at the end of the > filename. For example, if you deploy|MyClasses.jar|five times, the filename > is displayed as|vf.gf#MyClasses.jar#5|when you list all deployed jars. > > but,in my environment, it is shown as follows: > > gfsh>list deployed > Member | JAR | JAR Location > --- | -- | > --- > server1 | ra.jar | /media/liyujue/data/geode/server1/ra.v1.jar > server1 | mx4j-3.0.2.jar | > /media/liyujue/data/geode/server1/mx4j-3.0.2.v1.jar > server2 | ra.jar | /media/liyujue/data/geode/server2/ra.v1.jar > server2 | mx4j-3.0.2.jar | /media/liyujue/data/geode/server2/mx4j-3.0.2.v1.jar > The description here is incorrect. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-6584) Performance Improvement: Do not synchronize on volatile variables
[ https://issues.apache.org/jira/browse/GEODE-6584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dick Cavender closed GEODE-6584. > Performance Improvement: Do not synchronize on volatile variables > - > > Key: GEODE-6584 > URL: https://issues.apache.org/jira/browse/GEODE-6584 > Project: Geode > Issue Type: Improvement >Reporter: Helena Bales >Assignee: Helena Bales >Priority: Major > Labels: performance-benchmark > Fix For: 1.10.0 > > Time Spent: 1h > Remaining Estimate: 0h > > In ServerConnection, do not synchronize on volatile boolean processMessage. > It is not necessary and will have a negative performance impact. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-6593) ConnectionManagerJUnitTest.testBlocking is consistently failing on windows
[
https://issues.apache.org/jira/browse/GEODE-6593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dick Cavender closed GEODE-6593.
> ConnectionManagerJUnitTest.testBlocking is consistently failing on windows
> --
>
> Key: GEODE-6593
> URL: https://issues.apache.org/jira/browse/GEODE-6593
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.10.0
>Reporter: Dan Smith
>Assignee: Darrel Schneider
>Priority: Major
> Fix For: 1.10.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> This test seems to be failing consistently on windows after the changes for
> GEODE-6515. Looking at the test, it's doing a lot of Thread.sleep and timing
> related expectations, so maybe it's just a timing issue?
> {noformat}
> java.lang.AssertionError: Should have blocked for 100 millis for a connection
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerJUnitTest.testBlocking(ConnectionManagerJUnitTest.java:678)
> {noformat}
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsIntegrationTestOpenJDK8/builds/399
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.10.0-SNAPSHOT.0128/test-results/integrationTest/1554295015/classes/org.apache.geode.cache.client.internal.pooling.ConnectionManagerJUnitTest.html#testBlocking
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (GEODE-6742) JTA ExceptionsDUnitTest has no enabled tests
[ https://issues.apache.org/jira/browse/GEODE-6742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dick Cavender closed GEODE-6742. > JTA ExceptionsDUnitTest has no enabled tests > > > Key: GEODE-6742 > URL: https://issues.apache.org/jira/browse/GEODE-6742 > Project: Geode > Issue Type: Bug > Components: tests >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Fix For: 1.10.0 > > > ExceptionsDUnitTest needs some serious work to re-enable the potential test > coverage this test may have provided. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-6775) Remove unnecessary blank lines from gfsh output
[ https://issues.apache.org/jira/browse/GEODE-6775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dick Cavender closed GEODE-6775. > Remove unnecessary blank lines from gfsh output > --- > > Key: GEODE-6775 > URL: https://issues.apache.org/jira/browse/GEODE-6775 > Project: Geode > Issue Type: Improvement > Components: gfsh >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > Fix For: 1.10.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-4806) Replace SimpleTestSecurityManager with SimpleSecurityManager
[ https://issues.apache.org/jira/browse/GEODE-4806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dick Cavender closed GEODE-4806. > Replace SimpleTestSecurityManager with SimpleSecurityManager > > > Key: GEODE-4806 > URL: https://issues.apache.org/jira/browse/GEODE-4806 > Project: Geode > Issue Type: Task > Components: security >Reporter: Jens Deppe >Assignee: Sean Goller >Priority: Major > Labels: starter > Fix For: 1.10.0 > > Time Spent: 20m > Remaining Estimate: 0h > > These classes appear to be the same. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-6633) Remove JSON pretty printing from PdxToJSON
[
https://issues.apache.org/jira/browse/GEODE-6633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dick Cavender closed GEODE-6633.
> Remove JSON pretty printing from PdxToJSON
> --
>
> Key: GEODE-6633
> URL: https://issues.apache.org/jira/browse/GEODE-6633
> Project: Geode
> Issue Type: Improvement
> Components: gfsh, querying
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
> Fix For: 1.10.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> This will allow gfsh query results to display as single lines and not create
> multi-line output in tabular results.
> Currently it looks like this:
> {noformat}
> Command result for :
> Result : true
> Limit : 100
> Rows : 100
> name | address | street | city
> --- | | --- | ---
> name_16 | {
> "street" : "Main 16",
> "city" : "City 16"
> } | Main 16 | City 16
> name_82 | {
> "street" : "Main 82",
> "city" : "City 82"
> } | Main 82 | City 82
> name_1 | {
> "street" : "Main 1",
> "city" : "City 1"
> } | Main 1 | City 1
> name_44 | {
> "street" : "Main 44",
> "city" : "City 44"
> } | Main 44 | City 44
> name_48 | {
> "street" : "Main 48",
> "city" : "City 48"
> } | Main 48 | City 48{noformat}
> It should be more like this:
> {noformat}
> Command result for :
> Result : true
> Limit : 100
> Rows : 100
> name| address | street | city
> --- | - | --- | ---
> name_45 | {"street":"Main 45","city":"City 45"} | Main 45 | City 45
> name_3 | {"street":"Main 3","city":"City 3"} | Main 3 | City 3
> name_68 | {"street":"Main 68","city":"City 68"} | Main 68 | City 68
> name_60 | {"street":"Main 60","city":"City 60"} | Main 60 | City 60
> name_31 | {"street":"Main 31","city":"City 31"} | Main 31 | City 31{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (GEODE-6849) PRHARedundancyProvider.buildPartitionedRegionInfo should not depend on the value of PartitionedRegionStats
[ https://issues.apache.org/jira/browse/GEODE-6849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dick Cavender closed GEODE-6849. > PRHARedundancyProvider.buildPartitionedRegionInfo should not depend on the > value of PartitionedRegionStats > -- > > Key: GEODE-6849 > URL: https://issues.apache.org/jira/browse/GEODE-6849 > Project: Geode > Issue Type: Bug > Components: core >Reporter: Darrel Schneider >Assignee: Murtuza Boxwala >Priority: Major > Fix For: 1.10.0 > > Time Spent: 1.5h > Remaining Estimate: 0h > > Since geode stats can be disabled, geode features should not depend on the > value of stats. > Instead that information should be obtained from some other internal product > counter that can not be disabled. > PRHARedundancyProvider.buildPartitionedRegionInfo reads the following from > PartitionedRegionStats: getLowRedundancyBucketCount() and > getActualRedundantCopies() -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-6638) IllegalMonitorStateException could be thrown during cache close with concurrent committing transactions
[ https://issues.apache.org/jira/browse/GEODE-6638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dick Cavender closed GEODE-6638. > IllegalMonitorStateException could be thrown during cache close with > concurrent committing transactions > --- > > Key: GEODE-6638 > URL: https://issues.apache.org/jira/browse/GEODE-6638 > Project: Geode > Issue Type: Bug > Components: transactions >Affects Versions: 1.1.0 >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Fix For: 1.10.0 > > Time Spent: 20m > Remaining Estimate: 0h > > This could occur when a client transaction is being committed and locks are > hold by a thread. Another thread is concurrently closing the cache and try to > release the resources (including the transactions) and could hit this issue. > java.lang.IllegalMonitorStateException: attempt to unlock read lock, not > locked by current thread > at > java.util.concurrent.locks.ReentrantReadWriteLock$Sync.unmatchedUnlockException(ReentrantReadWriteLock.java:444) > at > java.util.concurrent.locks.ReentrantReadWriteLock$Sync.tryReleaseShared(ReentrantReadWriteLock.java:428) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.releaseShared(AbstractQueuedSynchronizer.java:1341) > at > java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.unlock(ReentrantReadWriteLock.java:881) > at > org.apache.geode.internal.util.concurrent.StoppableReentrantReadWriteLock$StoppableReadLock.unlock(StoppableReentrantReadWriteLock.java:144) > at > org.apache.geode.internal.cache.locks.TXLockServiceImpl.releaseRecoveryReadLock(TXLockServiceImpl.java:270) > at > org.apache.geode.internal.cache.locks.TXLockServiceImpl.release(TXLockServiceImpl.java:237) > at > org.apache.geode.internal.cache.TXLockRequest.releaseDistributed(TXLockRequest.java:109) > at > org.apache.geode.internal.cache.TXLockRequest.cleanup(TXLockRequest.java:142) > at org.apache.geode.internal.cache.TXState.doCleanup(TXState.java:886) > at org.apache.geode.internal.cache.TXState.cleanup(TXState.java:872) > at org.apache.geode.internal.cache.TXState.close(TXState.java:858) > at > org.apache.geode.internal.cache.TXStateProxyImpl.close(TXStateProxyImpl.java:924) > at > org.apache.geode.internal.cache.TXManagerImpl.removeHostedTXStatesForClients(TXManagerImpl.java:1076) > at > org.apache.geode.internal.cache.CacheServerImpl.stop(CacheServerImpl.java:484) > at > org.apache.geode.internal.cache.GemFireCacheImpl.stopServers(GemFireCacheImpl.java:2633) > at > org.apache.geode.internal.cache.GemFireCacheImpl.close(GemFireCacheImpl.java:2213) > at > org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect(InternalDistributedSystem.java:1363) > at > org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect(InternalDistributedSystem.java:1026) > at hydra.RemoteTestModule$3.run(RemoteTestModule.java:416) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-6557) Move admin rest classes into the geode-web project
[ https://issues.apache.org/jira/browse/GEODE-6557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dick Cavender closed GEODE-6557. > Move admin rest classes into the geode-web project > -- > > Key: GEODE-6557 > URL: https://issues.apache.org/jira/browse/GEODE-6557 > Project: Geode > Issue Type: Improvement > Components: rest (admin) >Reporter: Dan Smith >Assignee: Dan Smith >Priority: Major > Fix For: 1.10.0 > > Time Spent: 1h > Remaining Estimate: 0h > > For some reason, the classes needed for the geode-web war file were left in > geode-core. This results in a weird build and extra dependencies in > geode-core that aren't needed. The build currently jars these classes up > separately and uses them in the war, but they are not part of geode-core.jar. > These classes should move to geode-web. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-6544) Can't log back in Pulse after an unauthorized login attempt
[ https://issues.apache.org/jira/browse/GEODE-6544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dick Cavender closed GEODE-6544. > Can't log back in Pulse after an unauthorized login attempt > --- > > Key: GEODE-6544 > URL: https://issues.apache.org/jira/browse/GEODE-6544 > Project: Geode > Issue Type: Bug > Components: pulse >Reporter: Jinmei Liao >Assignee: Juan Ramos >Priority: Major > Fix For: 1.10.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Steps to reproduce: > 1) start a locator with security manager > 2) try login using a username/password that can be authenticated, but not > authorized to view the clusterDatail.html (no data.read privilege) > 3) user gets a 403, which is correct, but then user can not get back to the > login page to enter correct credentials. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-6750) Clean up Swagger UI model for Management API
[ https://issues.apache.org/jira/browse/GEODE-6750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dick Cavender closed GEODE-6750. > Clean up Swagger UI model for Management API > > > Key: GEODE-6750 > URL: https://issues.apache.org/jira/browse/GEODE-6750 > Project: Geode > Issue Type: Improvement > Components: management >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > Fix For: 1.10.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-6930) Lucene Functions specified using Internal Function's required permission, will be rejected by PCC
[ https://issues.apache.org/jira/browse/GEODE-6930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dick Cavender closed GEODE-6930. > Lucene Functions specified using Internal Function's required permission, > will be rejected by PCC > - > > Key: GEODE-6930 > URL: https://issues.apache.org/jira/browse/GEODE-6930 > Project: Geode > Issue Type: Bug > Components: lucene >Reporter: Xiaojian Zhou >Assignee: Xiaojian Zhou >Priority: Major > Labels: GeodeCommons > Fix For: 1.10.0 > > Time Spent: 1h > Remaining Estimate: 0h > > When playing lucene app, I noticed the query is rejected with following error > msg: > 2019-06-14T10:24:29.83-0700 [APP/PROC/WEB/0] OUT Caused by: > org.apache.geode.security.NotAuthorizedException: > developer_jNnlmXMEdwsrmaDayfNKg not authorized for * > This is because all the lucene functions are implementing Internal Function > but forgot to override it's getRequiredPermissions method. So it requires to > have ResourcePermissions.ALL to execute. > There're following 9 lucene functions: > WaitUntilFlushedFunction (Need READ) > LuceneQueryFunction (Need READ) > IndexingInProgressFunction (Need READ) > LuceneCreateIndexFunction (used by gfsh only, no need to change) > LuceneDestroyIndexFunction (used by gfsh only, no need to change) > LuceneDescribeIndexFunction (used by gfsh only, no need to change) > LuceneSearchIndexFunction (used by gfsh only, no need to change) > LuceneListIndexFunction (used by gfsh only, no need to change) > LuceneGetPageFunction (Need READ) > The 5 of them are only used by gfsh, which is the real "internal function". > The other 4 will be called by client application, so they should specify > ResourcePermissions.READ. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-6635) Native Client API docs: Use a 3-part version header
[ https://issues.apache.org/jira/browse/GEODE-6635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dick Cavender closed GEODE-6635. > Native Client API docs: Use a 3-part version header > --- > > Key: GEODE-6635 > URL: https://issues.apache.org/jira/browse/GEODE-6635 > Project: Geode > Issue Type: Improvement > Components: docs, native client >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Major > Fix For: 1.10.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Generate the C++ and .NET api docs with a 3-part version header > (major.minor.patch) instead of the current 2-part version header > (major.minor). > The 3-part header would be consistent with the current Geode convention, and > provides more precise information for the user. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-7007) Alter gfsh put docs to state prohibition on PDX objects
[
https://issues.apache.org/jira/browse/GEODE-7007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dick Cavender closed GEODE-7007.
> Alter gfsh put docs to state prohibition on PDX objects
> ---
>
> Key: GEODE-7007
> URL: https://issues.apache.org/jira/browse/GEODE-7007
> Project: Geode
> Issue Type: Improvement
> Components: docs
>Reporter: Karen Smoler Miller
>Assignee: Karen Smoler Miller
>Priority: Major
> Fix For: 1.10.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> You cannot use PDX objects with puts in gfsh.
> Example of a put command that will not work:
> gfsh>put --region=/CashflowGroupMap --key="Closure Margin"
> --value="('cashFlowType':'Closure Margin',
> 'cashFlowTypeGroup':'CMAR','activeIndicator':'A',
> 'updateDateTime':'2013-06-06 05:37:00.0')"
> --value-class=org.apache.geode.pdx.internal.PdxInstanceImpl
>
> Add this restriction in the docs. A good place to add it is in the gfsh
> command reference page.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (GEODE-6654) Stats documentation issues
[
https://issues.apache.org/jira/browse/GEODE-6654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dick Cavender closed GEODE-6654.
> Stats documentation issues
> --
>
> Key: GEODE-6654
> URL: https://issues.apache.org/jira/browse/GEODE-6654
> Project: Geode
> Issue Type: Bug
> Components: docs, statistics
>Reporter: Alberto Bustamante Reyes
>Assignee: Alberto Bustamante Reyes
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.10.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Hi,
> There is no information in documentation
> ([https://geode.apache.org/docs/guide/18/reference/statistics_list.html])
> about the following statistics:
> * Region Entry Eviction - Heap based eviction (HeapLRUStatistics)
> * Thread stats (VMThreadStats)
> * Client-to-Server communication (ClientSendStats)
> * Disk Store stats (DiskStoreStatistics)
>
> There are also these errors in statistics names (doc not aligned with code):
> * "Locator (LocatorStatistics)" should be "Locator
> ({color:#ff}LocatorStats{color})"
> * "Region Entry Eviction – Size-based (LRUStatistics)" should be "Region
> Entry Eviction – Size-based ({color:#ff}MemLRUStatistics{color})"
> * "Continuous Querying (CQStatistics)" should be "Continuous Querying
> ({color:#ff}CqQueryStats{color})"
> * "Gateway Queue (GatewayStatistics)" should be "Gateway Sender statistics
> ({color:#ff}GatewaySenderStatistics{color})"
> * "Function Execution (FunctionServiceStatistics)" should be "Function
> Execution ({color:#ff}FunctionStatistics{color})"
>
> Also, I cannot find references in the code about the "Delta Propagation
> (DeltaPropagationStatistics)" described in the documentation
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (GEODE-6875) Remove unused code and deprecated/internal API usages in Tomcat session state module
[ https://issues.apache.org/jira/browse/GEODE-6875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dick Cavender closed GEODE-6875. > Remove unused code and deprecated/internal API usages in Tomcat session state > module > > > Key: GEODE-6875 > URL: https://issues.apache.org/jira/browse/GEODE-6875 > Project: Geode > Issue Type: Improvement > Components: http session >Reporter: Ryan McMahon >Assignee: Juan Ramos >Priority: Major > Labels: GeodeCommons > Fix For: 1.10.0 > > Time Spent: 3h 50m > Remaining Estimate: 0h > > The Tomcat session state module has significant amounts of dead code as well > as deprecated/internal API usages. We should make a pass through and clean > this up. These reports can also be generated via IntelliJ's built-in report > tooling if it is more convenient. > - Go through the following report and delete all fully unused code > [https://drive.google.com/open?id=1W1bbKw2JE7CvcDajE9MyQhpCTSR_IeGw] > - Go through the following report and replace deprecated API usage with > correct API: > [https://drive.google.com/open?id=1b7RvM9Dbf85HsFLqVF7r5xYTEn5PbHOm|https://drive.google.com/drive/folders/1b7RvM9Dbf85HsFLqVF7r5xYTEn5PbHOm?usp=sharing] > - Identify areas we use internal Geode APIs and remove the usages if > possible, or determine why we cannot use them > [https://docs.google.com/document/d/1pvYIj0yvjy6xqRPzLEqE_Mp4t8Lj5yK45DbAoup-QZg/edit?usp=sharing] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-6734) Create Image pipeline red due to bad Java url in script
[ https://issues.apache.org/jira/browse/GEODE-6734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dick Cavender closed GEODE-6734. > Create Image pipeline red due to bad Java url in script > --- > > Key: GEODE-6734 > URL: https://issues.apache.org/jira/browse/GEODE-6734 > Project: Geode > Issue Type: Bug > Components: ci >Reporter: Robert Houghton >Priority: Major > Fix For: 1.10.0 > > Time Spent: 20m > Remaining Estimate: 0h > > build-google-geode-builder job is broken. Update the Docker/Packer to fix -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-2863) DiskStoreImpl close does not shutdown its thread pools
[ https://issues.apache.org/jira/browse/GEODE-2863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dick Cavender closed GEODE-2863. > DiskStoreImpl close does not shutdown its thread pools > -- > > Key: GEODE-2863 > URL: https://issues.apache.org/jira/browse/GEODE-2863 > Project: Geode > Issue Type: Bug > Components: persistence >Affects Versions: 1.0.0-incubating >Reporter: Darrel Schneider >Assignee: Mario Ivanac >Priority: Major > Labels: needs-review, pull-request-available, storage_3 > Fix For: 1.10.0 > > Time Spent: 1h > Remaining Estimate: 0h > > Closing a DiskStoreImpl does not shutdown its thread pools. > It has two pools, "diskStoreTaskPool" and "delayedWritePool", that it does > not shutdown. > However at least in some cases (see GEODE-2862) it does wait for all the > tasks submitted to these pools to complete. But it is not clear if additional > tasks could still be submitted after this wait is done. > Some logic should be added that causes the code that would submit a task to > these executors to no longer do so or, if needed, to process the task inline. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-6639) Remove lock contention in ServerConnection around processingMessageStartTime
[ https://issues.apache.org/jira/browse/GEODE-6639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dick Cavender closed GEODE-6639. > Remove lock contention in ServerConnection around processingMessageStartTime > > > Key: GEODE-6639 > URL: https://issues.apache.org/jira/browse/GEODE-6639 > Project: Geode > Issue Type: Improvement >Reporter: Jacob Barrett >Priority: Major > Labels: performance > Fix For: 1.10.0 > > Time Spent: 1.5h > Remaining Estimate: 0h > > Replace synchronized long with AtomicLong for value > processingMessageStartTime. Profiling shows minor lock contention for > something that could simply be atomic. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-6579) Creating a String during deserialization could be optimized
[ https://issues.apache.org/jira/browse/GEODE-6579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dick Cavender closed GEODE-6579. > Creating a String during deserialization could be optimized > --- > > Key: GEODE-6579 > URL: https://issues.apache.org/jira/browse/GEODE-6579 > Project: Geode > Issue Type: Improvement > Components: serialization >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: optimization > Fix For: 1.10.0 > > Time Spent: 2h 10m > Remaining Estimate: 0h > > When creating a string during deserialization from data that we know is in > the ASCII character set (each character can be represented by one byte) we > currently read all the bytes into a temporary byte array and then create a > String instance by giving it that byte array. The String constructor has to > create its own char array and then copy all the bytes into it. After that the > byte array is garbage. > We could instead directly create a char array, fill it by reading each byte > from the DataInput into it and then using reflection to directly set this > char array as the value field of the String instance we just created (as an > empty String). This prevents an extra copy of the data and reduces garbage > creation. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-2872) totalHitCount and totalMissCount incorrect for Partitioned Regions
[
https://issues.apache.org/jira/browse/GEODE-2872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dick Cavender closed GEODE-2872.
> totalHitCount and totalMissCount incorrect for Partitioned Regions
> --
>
> Key: GEODE-2872
> URL: https://issues.apache.org/jira/browse/GEODE-2872
> Project: Geode
> Issue Type: Bug
> Components: jmx, regions
>Reporter: Srikanth Manvi
>Assignee: Mario Kevo
>Priority: Major
> Labels: storage_3
> Fix For: 1.10.0
>
>
> The totalHitCount and totalMissCount values jump by 2 for each hit/miss
> operation instead of jumping by 1.
> Below are the steps:
> - Create a partitioned region with statistics enabled.
> - run _gfsh>show metrics_ and note the values of _totalHitCount_ and
> _totalMissCount_
> - Put an entry into the region retrieve it using _get_ and check the
> _totalHitCount_. The value would have doubled.
> - Run a _get_ on a key that is not in the region, and check the
> _totalMissCount_, it would have doubled.
> For a Partitioned region
> {code}
> gfsh>create region --name=Customer_Partition --enable-statistics=true
> --type=PARTITION
>Member | Status
> - | ---
> geode-server2 | Region "/Customer_Partition" created on "geode-server2"
> gfsh>show metrics
> Cluster-wide Metrics
> Category |Metric | Value
> - | - | -
> cluster | totalHeapSize | 10923
> cache | totalRegionEntryCount | 0
> | totalRegionCount | 3
> | totalMissCount| 1
> | totalHitCount | 5
> diskstore | totalDiskUsage| 0
> | diskReadsRate | 0
> | diskWritesRate| 0
> | flushTimeAvgLatency | 0
> | totalBackupInProgress | 0
> query | activeCQCount | 0
> | queryRequestRate | 0
> gfsh>get --key=404 --region=/Customer_Partition
> Result : false
> Key Class : java.lang.String
> Key : 404
> Value Class : java.lang.String
> Value :
> gfsh>show metrics
> Cluster-wide Metrics
> Category |Metric | Value
> - | - | -
> cluster | totalHeapSize | 10923
> cache | totalRegionEntryCount | 0
> | totalRegionCount | 3
> | totalMissCount| 3
> | totalHitCount | 5
> diskstore | totalDiskUsage| 0
> | diskReadsRate | 0
> | diskWritesRate| 0
> | flushTimeAvgLatency | 0
> | totalBackupInProgress | 0
> query | activeCQCount | 0
> | queryRequestRate | 0
> gfsh>put --key=1 --value="1" --region=/Customer_Partition
> Result : true
> Key Class : java.lang.String
> Key : 1
> Value Class : java.lang.String
> Old Value :
> gfsh>get --key=1 --region=/Customer_Partition
> Result : true
> Key Class : java.lang.String
> Key : 1
> Value Class : java.lang.String
> Value : 1
> gfsh>show metrics
> Cluster-wide Metrics
> Category |Metric | Value
> - | - | -
> cluster | totalHeapSize | 10923
> cache | totalRegionEntryCount | 1
> | totalRegionCount | 3
> | totalMissCount| 3
> | totalHitCount | 7
> diskstore | totalDiskUsage| 0
> | diskReadsRate | 0
> | diskWritesRate| 0
> | flushTimeAvgLatency | 0
> | totalBackupInProgress | 0
> query | activeCQCount | 0
> | queryRequestRate | 0
> {code}
> Version info -
> {code}
> gfsh>version --full
> Build-Date: 2017-03-27 21:52:42 -0700
> Build-Id: abaker 0
> Build-Java-Version: 1.8.0_121
> Build-Platform: Mac OS X 10.12.3 x86_64
> Product-Name: Apache Geode
> Product-Version: 1.1.1
> Source-Date: 2017-03-27 21:36:40 -0700
> Source-Repository: release/1.1.1
> Source-Revision: e2081044ea0afca1cb38d62c7f34e7363b45ad97
> Native version: native code unavailable
> Running on: /10.8.4.198, 8 cpu(s), x86_64 Mac OS X 10.11.6
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (GEODE-6866) gateway sender/async event queue consistency check can cause write ops to be applied to region but left out of queue
[ https://issues.apache.org/jira/browse/GEODE-6866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dick Cavender closed GEODE-6866. > gateway sender/async event queue consistency check can cause write ops to be > applied to region but left out of queue > > > Key: GEODE-6866 > URL: https://issues.apache.org/jira/browse/GEODE-6866 > Project: Geode > Issue Type: Bug > Components: wan >Reporter: Darrel Schneider >Priority: Major > Fix For: 1.10.0 > > > After a write operation has modified a region a check is done to see if the > gateway sender ids and async event queue ids are consistent across the entire > cluster. If they are consistent then the event is added to the > gateway/asyncEvent queue. But if they are not consistent an exception is > thrown. This will lead to items being in the region but never put in queue. > So at this point, instead of throwing an exception, we should just log a > warning about the inconsistent configuration and go ahead and deliver the > event to the gateways/asyncEventQueues that we do have. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-6768) "connection disconnect detected by EOF" should be a warning message and not info message
[ https://issues.apache.org/jira/browse/GEODE-6768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dick Cavender closed GEODE-6768. > "connection disconnect detected by EOF" should be a warning message and not > info message > > > Key: GEODE-6768 > URL: https://issues.apache.org/jira/browse/GEODE-6768 > Project: Geode > Issue Type: Improvement > Components: client/server >Reporter: Geet Rawat >Assignee: Geet Rawat >Priority: Major > Fix For: 1.10.0 > > Time Spent: 20m > Remaining Estimate: 0h > > When Clients are disconnected by EOF, there should be a warning log message. > At present, it's info level log message. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-6676) org.apache.geode.internal.ByteArrayDataInput.readUTF is not optimal for ASCII strings
[ https://issues.apache.org/jira/browse/GEODE-6676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dick Cavender closed GEODE-6676. > org.apache.geode.internal.ByteArrayDataInput.readUTF is not optimal for ASCII > strings > - > > Key: GEODE-6676 > URL: https://issues.apache.org/jira/browse/GEODE-6676 > Project: Geode > Issue Type: Improvement > Components: core >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Minor > Labels: performance > Fix For: 1.10.0 > > Time Spent: 20m > Remaining Estimate: 0h > > org.apache.geode.internal.ByteArrayDataInput.readUTF(), given ASCII bytes, > copies those bytes into a char array. It then allocates a new String with > that char array. > As of jdk 9, java.lang.String will take that char array and copy it back to a > byte array. > We can save a copy by using String(byte[], int, int, int). This does require > us to do a scan to make sure all the byte values are less than 128. As soon > as we see one that is not we can break out of the scan and do the normal utf > encode logic. But if all our Strings are ASCII, this will save a copy and the > char array used for UTF encoding never needs to be allocated. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-6535) ConnectionManagerImpl exchangeConnection and borrowConnection(ServerLocation) ignore their timeout parameter
[ https://issues.apache.org/jira/browse/GEODE-6535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dick Cavender closed GEODE-6535. > ConnectionManagerImpl exchangeConnection and borrowConnection(ServerLocation) > ignore their timeout parameter > > > Key: GEODE-6535 > URL: https://issues.apache.org/jira/browse/GEODE-6535 > Project: Geode > Issue Type: Bug > Components: client/server >Reporter: Darrel Schneider >Assignee: Mario Kevo >Priority: Major > Labels: needs-review, pull-request-available > Fix For: 1.10.0 > > Time Spent: 20m > Remaining Estimate: 0h > > The ConnectionManagerImpl methods exchangeConnection and > borrowConnection(ServerLocation) both have a timeout parameter that they > simply ignore. > They should either honor the timeout by waiting for an existing connection or > they should not take a timeout parameter. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-6702) InternalDistributedMember equals could be optimized
[ https://issues.apache.org/jira/browse/GEODE-6702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dick Cavender closed GEODE-6702. > InternalDistributedMember equals could be optimized > --- > > Key: GEODE-6702 > URL: https://issues.apache.org/jira/browse/GEODE-6702 > Project: Geode > Issue Type: Improvement > Components: core >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: performance > Fix For: 1.10.0 > > Time Spent: 1h 20m > Remaining Estimate: 0h > > In a partitioned region client/server put benchmark, I saw lots of calls to > InternalDistributedMember equals. Each call was allocating two byte arrays. > This is because equals is implemented by calling compareTo, and compare needs > to get the InetAddress as a byte array. But if instead it just wanted to know > if they were equal, then it could instead call InetAddress.equals. > I have a prototype fix for this in: > 4298ad678f3bc7621b6a566442e358f1ed34030a -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-6759) Prevent pool destruction if it's still in use and fix NPE in function execution
[
https://issues.apache.org/jira/browse/GEODE-6759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dick Cavender closed GEODE-6759.
> Prevent pool destruction if it's still in use and fix NPE in function
> execution
> ---
>
> Key: GEODE-6759
> URL: https://issues.apache.org/jira/browse/GEODE-6759
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Reporter: Juan Ramos
>Assignee: Juan Ramos
>Priority: Major
> Labels: GeodeCommons
> Fix For: 1.10.0
>
> Time Spent: 3.5h
> Remaining Estimate: 0h
>
> A {{NullPointerException}} can be thrown on client side if the application
> executes a function on a pool that has been destroyed.
> The following code reproduces the issue:
> {code:java}
> ClientCache clientCache = new ClientCacheFactory().create();
> PoolManager.createFactory().addLocator(InetAddress.getLocalHost().getHostName(),
> locator.getPort()).create("poolOne");
> Region region =
> clientCache.createClientRegionFactory(PROXY).setPoolName("poolOne").create("TestRegion");
> PoolManagerImpl.getPMI().unregister(PoolManager.find("poolOne"));
> FunctionService.onRegion(region).execute(testFunction).getResult();
> {code}
> The problem is that we don't verify whether the {{Pool}} is currently being
> used or not within the {{unregister}} method. The following should be done:
> # Don't allow the user to unregister the pool when at least one region is
> associated to it.
> # Throw a meaningful exception if the pool can't be found before executing
> the function.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (GEODE-6850) Deprecate "int" statistics in favor of "long" statistics
[ https://issues.apache.org/jira/browse/GEODE-6850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dick Cavender closed GEODE-6850. > Deprecate "int" statistics in favor of "long" statistics > > > Key: GEODE-6850 > URL: https://issues.apache.org/jira/browse/GEODE-6850 > Project: Geode > Issue Type: Improvement > Components: docs, statistics >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: docs > Fix For: 1.10.0 > > Time Spent: 1h > Remaining Estimate: 0h > > The "int" methods on the statistics interfaces have been deprecated. > They are on the Statistics interface and the StatisticsTypeFactory interface > (look for methods containing "Int") . > The implementation of these deprecated "int" methods now use the "long" > methods. > The only place this could be visible to a user is if they call > Statistics.get(String) or Statistics.get(StatisticDescriptor). Both of these > methods return a "Number" instance. > These methods continue to do this and existing code will work fine if it does > not try to downcast the Number to a subclass. But for "int" stats, these > methods used to return an "Integer" instance and now return a "Long" instance. -- This message was sent by Atlassian Jira (v8.3.4#803005)
