[jira] [Created] (GEODE-7851) Pulse should support OAuth2 authorization code flow
Jinmei Liao created GEODE-7851: -- Summary: Pulse should support OAuth2 authorization code flow Key: GEODE-7851 URL: https://issues.apache.org/jira/browse/GEODE-7851 Project: Geode Issue Type: New Feature Components: pulse Reporter: Jinmei Liao Instead of using username/password to log in to pulse, pulse should redirect to a configured authentication provider to get access token to login. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7818) Provide -h (--help) usage flag for backup and restore script
[ https://issues.apache.org/jira/browse/GEODE-7818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derrick Anderson updated GEODE-7818: Priority: Trivial (was: Major) > Provide -h (--help) usage flag for backup and restore script > > > Key: GEODE-7818 > URL: https://issues.apache.org/jira/browse/GEODE-7818 > Project: Geode > Issue Type: Improvement > Components: core, management, regions >Reporter: Derrick Anderson >Assignee: Derrick Anderson >Priority: Trivial > > As a cluster Administrator: > I would like to be able to see usage for the geode generated restore script > by passing a -h flag. > > This will allow for future enhancements to this script generator, such as > force delete of existing data, etc. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7849) change release urls from www.apache.org/dist/ to downloads.apache.org
[ https://issues.apache.org/jira/browse/GEODE-7849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17051739#comment-17051739 ] ASF subversion and git services commented on GEODE-7849: Commit d7e6c6e825d89c4155ad5b677e9c7f826e7c1d53 in geode-site's branch refs/heads/asf-site from David Barnes [ https://gitbox.apache.org/repos/asf?p=geode-site.git;h=d7e6c6e ] GEODE-7849: change release urls from www.apache.org/dist to downloads.apache.org > change release urls from www.apache.org/dist/ to downloads.apache.org > - > > Key: GEODE-7849 > URL: https://issues.apache.org/jira/browse/GEODE-7849 > Project: Geode > Issue Type: Improvement > Components: release, website >Reporter: Owen Nichols >Assignee: Owen Nichols >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > As requested by Apache on Mar 4, 2020 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7849) change release urls from www.apache.org/dist/ to downloads.apache.org
[ https://issues.apache.org/jira/browse/GEODE-7849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17051738#comment-17051738 ] ASF subversion and git services commented on GEODE-7849: Commit 1f2a460129fc845e4d204dd1b2030d0120988644 in geode-site's branch refs/heads/master from David Barnes [ https://gitbox.apache.org/repos/asf?p=geode-site.git;h=1f2a460 ] GEODE-7849: change release urls from www.apache.org/dist to downloads.apache.org > change release urls from www.apache.org/dist/ to downloads.apache.org > - > > Key: GEODE-7849 > URL: https://issues.apache.org/jira/browse/GEODE-7849 > Project: Geode > Issue Type: Improvement > Components: release, website >Reporter: Owen Nichols >Assignee: Owen Nichols >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > As requested by Apache on Mar 4, 2020 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7830) Management REST API rebalance endpoints return confusing operationResults
[
https://issues.apache.org/jira/browse/GEODE-7830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17051687#comment-17051687
]
Darrel Schneider commented on GEODE-7830:
-
You are right that the operator could check to see if any regions were
rebalanced. But couldn't the same argument be made that if we continue to
report this as a failure that the operator could check to see if it a failure
they are willing to ignore? So in either case, if you are willing to some extra
checking, you could figure out that it was or was not an error.
This part (what is and is not an error) of the rebalance implementation is
shared by the new REST API and gfsh. The REST API is new and subject to change
but gfsh rebalance has already been released. Since we already defined these
no-op rebalances as an error I'm inclined to keep it that way unless we think
this is a common use case.
> Management REST API rebalance endpoints return confusing operationResults
> -
>
> Key: GEODE-7830
> URL: https://issues.apache.org/jira/browse/GEODE-7830
> Project: Geode
> Issue Type: Bug
> Components: management
>Reporter: Aaron Lindsey
>Assignee: Darrel Schneider
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> We observed odd behavior regarding the operationResult object returned in the
> rebalance API:
> # It contains success=false if the cluster has no regions or has no servers.
> This is confusing because the rebalance didn't fail — it just didn't have
> anything to rebalance so it was basically a no-op. As a consumer of this API,
> I need to be able to distinguish between "real" failures and this "no-op"
> failure, and I should not have to write code to parse the "statusMessage" to
> do that.
> # Sometimes, success=true and other times success=false for the same
> statusMessage: "Distributed system has no regions that can be rebalanced."
> This is confusing because I don't know why it sometimes considers this a
> failure and other times considers it a success. If #1 above is fixed, then
> this would not be an issue because it would always return success=true for
> this particular statusMessage.
> Here is an example of two confusing operationResults we observed:
> {code:json}
> {
> "result": [
> {
> "statusCode": "OK",
> "links": {
> "self":
> "http://geodecluster-sample-locator.default/management/v1/operations/rebalances/15dfe6ef-acaf-4a45-9b55-1d855a977ba8;,
> "list":
> "http://geodecluster-sample-locator.default/management/v1/operations/rebalances;
> },
> "operationStart": "2020-02-25T18:53:34.058Z",
> "operationEnd": "2020-02-25T18:53:34.063Z",
> "operationId": "15dfe6ef-acaf-4a45-9b55-1d855a977ba8",
> "operation": {
> "simulate": false
> },
> "operationResult": {
> "statusMessage": "Distributed system has no regions that can be
> rebalanced.",
> "success": true
> }
> },
> {
> "statusCode": "OK",
> "links": {
> "self":
> "http://geodecluster-sample-locator.default/management/v1/operations/rebalances/8218ce0d-e3b8-4c49-b925-665a28e821c3;,
> "list":
> "http://geodecluster-sample-locator.default/management/v1/operations/rebalances;
> },
> "operationStart": "2020-02-25T18:53:45.650Z",
> "operationEnd": "2020-02-25T18:53:45.654Z",
> "operationId": "8218ce0d-e3b8-4c49-b925-665a28e821c3",
> "operation": {
> "simulate": false
> },
> "operationResult": {
> "statusMessage": "Distributed system has no regions that can be
> rebalanced.",
> "success": false
> }
> }
> ],
> "statusCode": "OK"
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (GEODE-6130) RAT is searching for sources relative to the Gradle daemon working directory
[ https://issues.apache.org/jira/browse/GEODE-6130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacob Barrett closed GEODE-6130. > RAT is searching for sources relative to the Gradle daemon working directory > > > Key: GEODE-6130 > URL: https://issues.apache.org/jira/browse/GEODE-6130 > Project: Geode > Issue Type: Bug > Components: build >Reporter: Jacob Barrett >Assignee: Jacob Barrett >Priority: Major > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > RAT is searching for sources relative to the Gradle daemon working directory > by default rather than the project root. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-7850) Implement Rename Command in Geode Redis Module
John Hutchison created GEODE-7850: - Summary: Implement Rename Command in Geode Redis Module Key: GEODE-7850 URL: https://issues.apache.org/jira/browse/GEODE-7850 Project: Geode Issue Type: New Feature Components: redis Reporter: John Hutchison Allows user to rename a key within the Geode-Redis-Module. This PR only implements the functionality for Hashes, Sets, and Strings. As other datatypes are migrated away from single region for single key, rename command will be implemented for those data types. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7808) standardize on use of LocatorAddress/HostAddress for connection formation
[ https://issues.apache.org/jira/browse/GEODE-7808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17051632#comment-17051632 ] ASF subversion and git services commented on GEODE-7808: Commit 5c2b959e98a6330ecaeddb4d26e11ea29f7a2d7f in geode's branch refs/heads/develop from Bruce Schuchardt [ https://gitbox.apache.org/repos/asf?p=geode.git;h=5c2b959 ] GEODE-7808: standardize on use of HostAndPort for creating connections (#4765) * Squashed merge of feature/GEODE-7808 removed HostAddress renamed LocatorAddress to HostAndPort modified TcpClient methods to take a HostAndPort argument instead of InetAddress modified SocketCreator to take a HostAndPort argument instead of InetAddress * GEODE-7808 - standardize on use of HostAndPort for connection formation This continues a previous PR that passed and was approved for merge. This commit raises up several methods from SocketCreator into the TcpSocketCreator interface. This is an intermediate commit. A subsequent commit will refactor TcpSocketCreator to separate the client and server methods for creating server-sockets and client connections to server-sockets. * refactored socket-creators to separate concerns ServerSocketCreator holds methods for non-client comms ClientSocketCreator holds methods that clients should use for comms AdvancedSocketCreator holds methods for people who need to get around the limitations of the other two interfaces * adding missing interface * move code out of inner-classes into first-class classes * renaming interfaces and methods to be less confusing * reinstate SocketCreator ip to hostname cache for performance * changes from review comments > standardize on use of LocatorAddress/HostAddress for connection formation > - > > Key: GEODE-7808 > URL: https://issues.apache.org/jira/browse/GEODE-7808 > Project: Geode > Issue Type: Improvement > Components: membership, messaging >Reporter: Bruce J Schuchardt >Assignee: Bruce J Schuchardt >Priority: Major > Fix For: 1.13.0 > > Time Spent: 6h 50m > Remaining Estimate: 0h > > We currently use InetAddress and InetSocketAddress in many places to identify > locators, servers and peers. Some work has been done in the past couple of > years to reduce the use of these in order to accommodate changes in IP > addresses due to various causes. The class LocatorAddress was created to > help with this and it is able to hold a host name without resolving it until > that resolution is needed to form a tcp/ip connection. > These days we are seeing more and more movement into cloud computing and the > need to accommodate IP address changes is becoming a bigger issue. To that > end we would like to change our primary client/server and WAN communication > interfaces to stop taking InetAddresses and InetSocketAddresses as arguments > and, instead, take something like a LocatorAddress that can hold an > unresolved hostname that our communication implementations will resolve when > needed. > To that end we should also remove the hostname->inetaddress cache in > SocketCreator and rely on the operating system's DNS cache. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7808) standardize on use of LocatorAddress/HostAddress for connection formation
[ https://issues.apache.org/jira/browse/GEODE-7808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17051634#comment-17051634 ] ASF subversion and git services commented on GEODE-7808: Commit 5c2b959e98a6330ecaeddb4d26e11ea29f7a2d7f in geode's branch refs/heads/develop from Bruce Schuchardt [ https://gitbox.apache.org/repos/asf?p=geode.git;h=5c2b959 ] GEODE-7808: standardize on use of HostAndPort for creating connections (#4765) * Squashed merge of feature/GEODE-7808 removed HostAddress renamed LocatorAddress to HostAndPort modified TcpClient methods to take a HostAndPort argument instead of InetAddress modified SocketCreator to take a HostAndPort argument instead of InetAddress * GEODE-7808 - standardize on use of HostAndPort for connection formation This continues a previous PR that passed and was approved for merge. This commit raises up several methods from SocketCreator into the TcpSocketCreator interface. This is an intermediate commit. A subsequent commit will refactor TcpSocketCreator to separate the client and server methods for creating server-sockets and client connections to server-sockets. * refactored socket-creators to separate concerns ServerSocketCreator holds methods for non-client comms ClientSocketCreator holds methods that clients should use for comms AdvancedSocketCreator holds methods for people who need to get around the limitations of the other two interfaces * adding missing interface * move code out of inner-classes into first-class classes * renaming interfaces and methods to be less confusing * reinstate SocketCreator ip to hostname cache for performance * changes from review comments > standardize on use of LocatorAddress/HostAddress for connection formation > - > > Key: GEODE-7808 > URL: https://issues.apache.org/jira/browse/GEODE-7808 > Project: Geode > Issue Type: Improvement > Components: membership, messaging >Reporter: Bruce J Schuchardt >Assignee: Bruce J Schuchardt >Priority: Major > Fix For: 1.13.0 > > Time Spent: 6h 50m > Remaining Estimate: 0h > > We currently use InetAddress and InetSocketAddress in many places to identify > locators, servers and peers. Some work has been done in the past couple of > years to reduce the use of these in order to accommodate changes in IP > addresses due to various causes. The class LocatorAddress was created to > help with this and it is able to hold a host name without resolving it until > that resolution is needed to form a tcp/ip connection. > These days we are seeing more and more movement into cloud computing and the > need to accommodate IP address changes is becoming a bigger issue. To that > end we would like to change our primary client/server and WAN communication > interfaces to stop taking InetAddresses and InetSocketAddresses as arguments > and, instead, take something like a LocatorAddress that can hold an > unresolved hostname that our communication implementations will resolve when > needed. > To that end we should also remove the hostname->inetaddress cache in > SocketCreator and rely on the operating system's DNS cache. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7808) standardize on use of LocatorAddress/HostAddress for connection formation
[ https://issues.apache.org/jira/browse/GEODE-7808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17051633#comment-17051633 ] ASF subversion and git services commented on GEODE-7808: Commit 5c2b959e98a6330ecaeddb4d26e11ea29f7a2d7f in geode's branch refs/heads/develop from Bruce Schuchardt [ https://gitbox.apache.org/repos/asf?p=geode.git;h=5c2b959 ] GEODE-7808: standardize on use of HostAndPort for creating connections (#4765) * Squashed merge of feature/GEODE-7808 removed HostAddress renamed LocatorAddress to HostAndPort modified TcpClient methods to take a HostAndPort argument instead of InetAddress modified SocketCreator to take a HostAndPort argument instead of InetAddress * GEODE-7808 - standardize on use of HostAndPort for connection formation This continues a previous PR that passed and was approved for merge. This commit raises up several methods from SocketCreator into the TcpSocketCreator interface. This is an intermediate commit. A subsequent commit will refactor TcpSocketCreator to separate the client and server methods for creating server-sockets and client connections to server-sockets. * refactored socket-creators to separate concerns ServerSocketCreator holds methods for non-client comms ClientSocketCreator holds methods that clients should use for comms AdvancedSocketCreator holds methods for people who need to get around the limitations of the other two interfaces * adding missing interface * move code out of inner-classes into first-class classes * renaming interfaces and methods to be less confusing * reinstate SocketCreator ip to hostname cache for performance * changes from review comments > standardize on use of LocatorAddress/HostAddress for connection formation > - > > Key: GEODE-7808 > URL: https://issues.apache.org/jira/browse/GEODE-7808 > Project: Geode > Issue Type: Improvement > Components: membership, messaging >Reporter: Bruce J Schuchardt >Assignee: Bruce J Schuchardt >Priority: Major > Fix For: 1.13.0 > > Time Spent: 6h 50m > Remaining Estimate: 0h > > We currently use InetAddress and InetSocketAddress in many places to identify > locators, servers and peers. Some work has been done in the past couple of > years to reduce the use of these in order to accommodate changes in IP > addresses due to various causes. The class LocatorAddress was created to > help with this and it is able to hold a host name without resolving it until > that resolution is needed to form a tcp/ip connection. > These days we are seeing more and more movement into cloud computing and the > need to accommodate IP address changes is becoming a bigger issue. To that > end we would like to change our primary client/server and WAN communication > interfaces to stop taking InetAddresses and InetSocketAddresses as arguments > and, instead, take something like a LocatorAddress that can hold an > unresolved hostname that our communication implementations will resolve when > needed. > To that end we should also remove the hostname->inetaddress cache in > SocketCreator and rely on the operating system's DNS cache. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-6903) CI Failure: GemFireTransactionDataSourceIntegrationTest.testExceptionHandlingGetConnection failed with Assertion
[
https://issues.apache.org/jira/browse/GEODE-6903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund reassigned GEODE-6903:
Assignee: Kirk Lund
> CI Failure:
> GemFireTransactionDataSourceIntegrationTest.testExceptionHandlingGetConnection
> failed with Assertion
>
>
> Key: GEODE-6903
> URL: https://issues.apache.org/jira/browse/GEODE-6903
> Project: Geode
> Issue Type: Bug
> Components: transactions
>Reporter: Eric Shu
>Assignee: Kirk Lund
>Priority: Major
> Labels: flaky
>
> {noformat}
> org.apache.geode.internal.datasource.GemFireTransactionDataSourceIntegrationTest
> > testExceptionHandlingGetConnection FAILED
> org.junit.ComparisonFailure: expected:<[0]> but was:<[2]>
> at sun.reflect.GeneratedConstructorAccessor26.newInstance(Unknown
> Source)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.internal.datasource.GemFireTransactionDataSourceIntegrationTest.testExceptionHandlingGetConnection(GemFireTransactionDataSourceIntegrationTest.java:141)
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.10.0-SNAPSHOT.0399/test-results/integrationTest/1561170841/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.10.0-SNAPSHOT.0399/test-artifacts/1561170841/integrationtestfiles-OpenJDK8-1.10.0-SNAPSHOT.0399.tgz
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-7849) change release urls from www.apache.org/dist/ to downloads.apache.org
[ https://issues.apache.org/jira/browse/GEODE-7849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols reassigned GEODE-7849: --- Assignee: Owen Nichols > change release urls from www.apache.org/dist/ to downloads.apache.org > - > > Key: GEODE-7849 > URL: https://issues.apache.org/jira/browse/GEODE-7849 > Project: Geode > Issue Type: Improvement > Components: release, website >Reporter: Owen Nichols >Assignee: Owen Nichols >Priority: Major > > As requested by Apache on Mar 4, 2020 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-7849) change release urls from www.apache.org/dist/ to downloads.apache.org
Owen Nichols created GEODE-7849: --- Summary: change release urls from www.apache.org/dist/ to downloads.apache.org Key: GEODE-7849 URL: https://issues.apache.org/jira/browse/GEODE-7849 Project: Geode Issue Type: Improvement Components: release, website Reporter: Owen Nichols As requested by Apache on Mar 4, 2020 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-7848) Remove NonCopyable and NonAssignable inheritance.
Matthew Reddington created GEODE-7848: - Summary: Remove NonCopyable and NonAssignable inheritance. Key: GEODE-7848 URL: https://issues.apache.org/jira/browse/GEODE-7848 Project: Geode Issue Type: Improvement Components: native client Reporter: Matthew Reddington Remove all instances of NonCopyable and NonAssignable inheritance from the native client and replace it with a deleted copy constructor and assignment operator in public scope (which helps with compiler error messages). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7847) Clear in PR could fail with Partial result, need to send to caller with an exception
[ https://issues.apache.org/jira/browse/GEODE-7847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xiaojian Zhou updated GEODE-7847: - Labels: GeodeCommons (was: ) > Clear in PR could fail with Partial result, need to send to caller with an > exception > > > Key: GEODE-7847 > URL: https://issues.apache.org/jira/browse/GEODE-7847 > Project: Geode > Issue Type: Improvement > Components: core >Reporter: Xiaojian Zhou >Priority: Major > Labels: GeodeCommons > > In the case of PartitionOfflineException, clear will fail with some of the > buckets cleared, some are not. Need to send back the caller with partial > result exception and let the caller to decide if to retry. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-7847) Clear in PR could fail with Partial result, need to send to caller with an exception
Xiaojian Zhou created GEODE-7847: Summary: Clear in PR could fail with Partial result, need to send to caller with an exception Key: GEODE-7847 URL: https://issues.apache.org/jira/browse/GEODE-7847 Project: Geode Issue Type: Improvement Components: core Reporter: Xiaojian Zhou In the case of PartitionOfflineException, clear will fail with some of the buckets cleared, some are not. Need to send back the caller with partial result exception and let the caller to decide if to retry. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7846) Clear in Partitioned Region should have its own stats
[ https://issues.apache.org/jira/browse/GEODE-7846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xiaojian Zhou updated GEODE-7846: - Labels: GeodeCommons (was: ) > Clear in Partitioned Region should have its own stats > - > > Key: GEODE-7846 > URL: https://issues.apache.org/jira/browse/GEODE-7846 > Project: Geode > Issue Type: Improvement > Components: core >Reporter: Xiaojian Zhou >Priority: Major > Labels: GeodeCommons > > Clear operation in PR should have its own stats: > 1) clear operation executed. > 2) clear operation failed > 3) clear messages sends to buckets -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-7846) Clear in Partitioned Region should have its own stats
Xiaojian Zhou created GEODE-7846: Summary: Clear in Partitioned Region should have its own stats Key: GEODE-7846 URL: https://issues.apache.org/jira/browse/GEODE-7846 Project: Geode Issue Type: Improvement Components: core Reporter: Xiaojian Zhou Clear operation in PR should have its own stats: 1) clear operation executed. 2) clear operation failed 3) clear messages sends to buckets -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7845) Rollingupgrade should not conflict with the new ClearPRMessage
[ https://issues.apache.org/jira/browse/GEODE-7845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xiaojian Zhou updated GEODE-7845: - Labels: GeodeCommons (was: ) > Rollingupgrade should not conflict with the new ClearPRMessage > --- > > Key: GEODE-7845 > URL: https://issues.apache.org/jira/browse/GEODE-7845 > Project: Geode > Issue Type: Improvement > Components: core >Reporter: Xiaojian Zhou >Priority: Major > Labels: GeodeCommons > > PartitionedRegion clear introduced a new ClearPRMessage. In case of doing > rolling upgrade, the user called PR.clear. The new ClearPRMessage should not > fail. It should not be sent to the old members. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-7845) Rollingupgrade should not conflict with the new ClearPRMessage
Xiaojian Zhou created GEODE-7845: Summary: Rollingupgrade should not conflict with the new ClearPRMessage Key: GEODE-7845 URL: https://issues.apache.org/jira/browse/GEODE-7845 Project: Geode Issue Type: Improvement Components: core Reporter: Xiaojian Zhou PartitionedRegion clear introduced a new ClearPRMessage. In case of doing rolling upgrade, the user called PR.clear. The new ClearPRMessage should not fail. It should not be sent to the old members. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7844) Refactor sendMsgByBucket and sendClearMsgByBucket not to use duplicated code
[ https://issues.apache.org/jira/browse/GEODE-7844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xiaojian Zhou updated GEODE-7844: - Labels: GeodeCommons (was: ) > Refactor sendMsgByBucket and sendClearMsgByBucket not to use duplicated code > > > Key: GEODE-7844 > URL: https://issues.apache.org/jira/browse/GEODE-7844 > Project: Geode > Issue Type: Improvement > Components: core >Reporter: Xiaojian Zhou >Priority: Major > Labels: GeodeCommons > > In PartitionedRegion class, there're 2 sendMsgByBucket() methods, one for > PutAll, another is for RemoveAll. We are adding the 3rd one for Clear. > Their logic are duplicated in most part. Need to refactor the 3 methods to > avoid duplicate code. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-7844) Refactor sendMsgByBucket and sendClearMsgByBucket not to use duplicated code
Xiaojian Zhou created GEODE-7844: Summary: Refactor sendMsgByBucket and sendClearMsgByBucket not to use duplicated code Key: GEODE-7844 URL: https://issues.apache.org/jira/browse/GEODE-7844 Project: Geode Issue Type: Improvement Components: core Reporter: Xiaojian Zhou In PartitionedRegion class, there're 2 sendMsgByBucket() methods, one for PutAll, another is for RemoveAll. We are adding the 3rd one for Clear. Their logic are duplicated in most part. Need to refactor the 3 methods to avoid duplicate code. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-7842) Improve concurrent region creation
[
https://issues.apache.org/jira/browse/GEODE-7842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Deppe resolved GEODE-7842.
---
Fix Version/s: 1.13.0
Resolution: Fixed
> Improve concurrent region creation
> --
>
> Key: GEODE-7842
> URL: https://issues.apache.org/jira/browse/GEODE-7842
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
> Fix For: 1.13.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> The Redis adapter has some tests that result in regions being attempted to be
> created concurrently. The region create call uses {{ifNotExists=true}} but
> occasionally I still see {{RegionCreationException}}s as multiple threads are
> in the {{RegionCreateFunction}} concurrently trying to create the same region.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7842) Improve concurrent region creation
[
https://issues.apache.org/jira/browse/GEODE-7842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17051537#comment-17051537
]
ASF subversion and git services commented on GEODE-7842:
Commit a5c8e2bc0e41bf591c24e44e1cbfe48c3ca59e7b in geode's branch
refs/heads/develop from Jens Deppe
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=a5c8e2b ]
GEODE-7842: Improve concurrent region creation (#4767)
> Improve concurrent region creation
> --
>
> Key: GEODE-7842
> URL: https://issues.apache.org/jira/browse/GEODE-7842
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
> Fix For: 1.13.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> The Redis adapter has some tests that result in regions being attempted to be
> created concurrently. The region create call uses {{ifNotExists=true}} but
> occasionally I still see {{RegionCreationException}}s as multiple threads are
> in the {{RegionCreateFunction}} concurrently trying to create the same region.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-7683) Implement the Bucket Region cmnClearRegion
[ https://issues.apache.org/jira/browse/GEODE-7683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xiaojian Zhou reassigned GEODE-7683: Assignee: Xiaojian Zhou > Implement the Bucket Region cmnClearRegion > --- > > Key: GEODE-7683 > URL: https://issues.apache.org/jira/browse/GEODE-7683 > Project: Geode > Issue Type: New Feature > Components: regions >Reporter: Nabarun Nag >Assignee: Xiaojian Zhou >Priority: Major > Labels: GeodeCommons > Fix For: 1.13.0 > > Time Spent: 4h > Remaining Estimate: 0h > > Implement the method to clear up a bucket region -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7460) CI failure: DistributedMemberDUnitTest.testGroupsInAllVMs Failure
[
https://issues.apache.org/jira/browse/GEODE-7460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17051508#comment-17051508
]
Mark Hanson commented on GEODE-7460:
more mass test run failures 3-4-2020
{noformat}
testGroupsInAllVMs
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/936
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/924
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/800
{noformat}
> CI failure: DistributedMemberDUnitTest.testGroupsInAllVMs Failure
> -
>
> Key: GEODE-7460
> URL: https://issues.apache.org/jira/browse/GEODE-7460
> Project: Geode
> Issue Type: Bug
> Components: membership
>Reporter: Robert Houghton
>Assignee: Bill Burcham
>Priority: Major
> Fix For: 1.12.0
>
>
> From the failing job:
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.12.0-SNAPSHOT.0016/test-results/distributedTest/1573784422/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.12.0-SNAPSHOT.0016/test-artifacts/1573784422/distributedtestfiles-OpenJDK8-1.12.0-SNAPSHOT.0016.tgz
> DistributedTest failure due to exception:
> org.apache.geode.distributed.DistributedMemberDUnitTest > testGroupsInAllVMs
> FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.distributed.DistributedMemberDUnitTest$6.run in VM 0 running
> on Host 3e09f1029b44 with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:579)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:406)
> at
> org.apache.geode.distributed.DistributedMemberDUnitTest.testGroupsInAllVMs(DistributedMemberDUnitTest.java:333)
> Caused by:
> org.apache.geode.SystemConnectException: One or more peers generated
> exceptions during connection attempt
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendStartupMessage(ClusterDistributionManager.java:1625)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:354)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:759)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.access$200(InternalDistributedSystem.java:136)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem$Builder.build(InternalDistributedSystem.java:3009)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:269)
> at
> org.apache.geode.distributed.DistributedSystem.connect(DistributedSystem.java:159)
> at
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.getSystem(JUnit4DistributedTestCase.java:181)
> at
> org.apache.geode.distributed.DistributedMemberDUnitTest$6.run(DistributedMemberDUnitTest.java:339)
> Caused by:
>
> org.apache.geode.distributed.DistributedSystemDisconnectedException:
> DistributedSystem is shutting down, caused by
> org.apache.geode.ForcedDisconnectException: Exiting due to possible network
> partition event due to loss of 1 cache processes:
> [172.17.0.14(myName:1):41001]
> at
> org.apache.geode.distributed.internal.membership.adapter.GMSMembershipManager.directChannelSend(GMSMembershipManager.java:1591)
> at
> org.apache.geode.distributed.internal.membership.adapter.GMSMembershipManager.send(GMSMembershipManager.java:1751)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2058)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:1985)
> at
> org.apache.geode.distributed.internal.StartupOperation.sendStartupMessage(StartupOperation.java:74)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendStartupMessage(ClusterDistributionManager.java:1622)
> ... 8 more
> Caused by:
> org.apache.geode.ForcedDisconnectException: Exiting due to
> possible network partition event due to loss of 1 cache processes:
>
[jira] [Commented] (GEODE-6819) CI failure: PartitionedRegionSingleHopDUnitTest. testMetadataIsSameOnAllServersAndClients
[
https://issues.apache.org/jira/browse/GEODE-6819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17051507#comment-17051507
]
Mark Hanson commented on GEODE-6819:
More mass-test-run failures on 3-4-2020
{noformat}
testMetadataServiceCallAccuracy
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/783
testMetadataIsSameOnAllServersAndClients
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/776
{noformat}
> CI failure: PartitionedRegionSingleHopDUnitTest.
> testMetadataIsSameOnAllServersAndClients
> -
>
> Key: GEODE-6819
> URL: https://issues.apache.org/jira/browse/GEODE-6819
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Reporter: Bruce J Schuchardt
>Assignee: Ivan Godwin
>Priority: Major
> Labels: flaky
> Fix For: 1.12.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> {noformat}
> org.apache.geode.internal.cache.PartitionedRegionSingleHopDUnitTest >
> testMetadataIsSameOnAllServersAndClients FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined in public void
> org.apache.geode.internal.cache.PartitionedRegionSingleHopDUnitTest.testMetadataIsSameOnAllServersAndClients()
> bucket copies are not created within 300 seconds.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:145)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:122)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:32)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:902)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:723)
> at
> org.apache.geode.internal.cache.PartitionedRegionSingleHopDUnitTest.testMetadataIsSameOnAllServersAndClients(PartitionedRegionSingleHopDUnitTest.java:849)
> Caused by:
> java.lang.AssertionError: bucket copies are not created{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Reopened] (GEODE-6819) CI failure: PartitionedRegionSingleHopDUnitTest. testMetadataIsSameOnAllServersAndClients
[
https://issues.apache.org/jira/browse/GEODE-6819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Hanson reopened GEODE-6819:
> CI failure: PartitionedRegionSingleHopDUnitTest.
> testMetadataIsSameOnAllServersAndClients
> -
>
> Key: GEODE-6819
> URL: https://issues.apache.org/jira/browse/GEODE-6819
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Reporter: Bruce J Schuchardt
>Assignee: Ivan Godwin
>Priority: Major
> Labels: flaky
> Fix For: 1.12.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> {noformat}
> org.apache.geode.internal.cache.PartitionedRegionSingleHopDUnitTest >
> testMetadataIsSameOnAllServersAndClients FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined in public void
> org.apache.geode.internal.cache.PartitionedRegionSingleHopDUnitTest.testMetadataIsSameOnAllServersAndClients()
> bucket copies are not created within 300 seconds.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:145)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:122)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:32)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:902)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:723)
> at
> org.apache.geode.internal.cache.PartitionedRegionSingleHopDUnitTest.testMetadataIsSameOnAllServersAndClients(PartitionedRegionSingleHopDUnitTest.java:849)
> Caused by:
> java.lang.AssertionError: bucket copies are not created{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7474) NetSearchMessagingDUnitTest.testNetSearchFailoverFromReplicate
[
https://issues.apache.org/jira/browse/GEODE-7474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17051504#comment-17051504
]
Mark Hanson commented on GEODE-7474:
more failures in mass-test-run on 3-4-2020
{noformat}
testNetSearchFailoverFromReplicate
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/948
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/838{noformat}
> NetSearchMessagingDUnitTest.testNetSearchFailoverFromReplicate
> --
>
> Key: GEODE-7474
> URL: https://issues.apache.org/jira/browse/GEODE-7474
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Mark Hanson
>Assignee: Ivan Godwin
>Priority: Major
> Labels: flaky
> Fix For: 1.12.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/mhansonp-mhanson-mass-test-ru-main/jobs/DistributedTestOpenJDK8/builds/1665]
>
> {noformat}
> org.apache.geode.internal.cache.NetSearchMessagingDUnitTest >
> testNetSearchFailoverFromReplicate FAILED
> 19:13:08java.lang.AssertionError: Suspicious strings were written to the
> log during this run.
> 19:13:08Fix the strings or use IgnoredException.addIgnoredException to
> ignore.
> 19:13:08
> ---
> 19:13:08Found suspect string in log4j at line 2385
> 19:13:08
> 19:13:08[fatal 2019/11/18 03:13:06.977 GMT thread 2> tid=207] Uncaught exception in thread Thread[Geode Failure
> Detection thread 2,5,RMI Runtime]
> 19:13:08java.util.concurrent.RejectedExecutionException: Task
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor$$Lambda$226/1317859019@1274aba9
> rejected from java.util.concurrent.ThreadPoolExecutor@100274c7[Shutting
> down, pool size = 3, active threads = 3, queued tasks = 0, completed tasks =
> 7]
> 19:13:08 at
> java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2063)
> 19:13:08 at
> java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:830)
> 19:13:08 at
> java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1379)
> 19:13:08 at
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.checkIfAvailable(GMSHealthMonitor.java:1295)
> 19:13:08 at
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.processMessage(GMSHealthMonitor.java:1232)
> 19:13:08 at
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.sendSuspectRequest(GMSHealthMonitor.java:1478)
> 19:13:08 at
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.initiateSuspicion(GMSHealthMonitor.java:477)
> 19:13:08 at
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.lambda$checkMember$0(GMSHealthMonitor.java:461)
> 19:13:08 at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> 19:13:08 at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> 19:13:08 at java.lang.Thread.run(Thread.java:748)
> 19:13:08
> 19:13:08
> ---
> 19:13:08Found suspect string in log4j at line 2399
> 19:13:08
> 19:13:08[fatal 2019/11/18 03:13:06.976 GMT thread 4> tid=226] Uncaught exception in thread Thread[Geode Failure
> Detection thread 4,5,RMI Runtime]
> 19:13:08java.util.concurrent.RejectedExecutionException: Task
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor$$Lambda$226/1317859019@143de298
> rejected from java.util.concurrent.ThreadPoolExecutor@100274c7[Shutting
> down, pool size = 3, active threads = 3, queued tasks = 0, completed tasks =
> 7]
> 19:13:08 at
> java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2063)
> 19:13:08 at
> java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:830)
> 19:13:08 at
> java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1379)
> 19:13:08 at
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.checkIfAvailable(GMSHealthMonitor.java:1295)
> 19:13:08 at
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.processMessage(GMSHealthMonitor.java:1232)
> 19:13:08 at
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.sendSuspectRequest(GMSHealthMonitor.java:1478)
> 19:13:08 at
>
[jira] [Commented] (GEODE-7830) Management REST API rebalance endpoints return confusing operationResults
[
https://issues.apache.org/jira/browse/GEODE-7830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17051486#comment-17051486
]
Aaron Lindsey commented on GEODE-7830:
--
[~dschneider] Thanks for that perspective. I agree that there might be a
situation where an operator tries to perform a rebalance, but the rebalance
does not do what they expect due to regions/servers not being online yet. In
that specific case, however, the operator could check the
rebalanceRegionResults which is included in the operationResult and see that it
is empty which means that there are no regions that were actually rebalanced.
Then they would know that the rebalance didn't do what they intended.
> Management REST API rebalance endpoints return confusing operationResults
> -
>
> Key: GEODE-7830
> URL: https://issues.apache.org/jira/browse/GEODE-7830
> Project: Geode
> Issue Type: Bug
> Components: management
>Reporter: Aaron Lindsey
>Assignee: Darrel Schneider
>Priority: Major
>
> We observed odd behavior regarding the operationResult object returned in the
> rebalance API:
> # It contains success=false if the cluster has no regions or has no servers.
> This is confusing because the rebalance didn't fail — it just didn't have
> anything to rebalance so it was basically a no-op. As a consumer of this API,
> I need to be able to distinguish between "real" failures and this "no-op"
> failure, and I should not have to write code to parse the "statusMessage" to
> do that.
> # Sometimes, success=true and other times success=false for the same
> statusMessage: "Distributed system has no regions that can be rebalanced."
> This is confusing because I don't know why it sometimes considers this a
> failure and other times considers it a success. If #1 above is fixed, then
> this would not be an issue because it would always return success=true for
> this particular statusMessage.
> Here is an example of two confusing operationResults we observed:
> {code:json}
> {
> "result": [
> {
> "statusCode": "OK",
> "links": {
> "self":
> "http://geodecluster-sample-locator.default/management/v1/operations/rebalances/15dfe6ef-acaf-4a45-9b55-1d855a977ba8;,
> "list":
> "http://geodecluster-sample-locator.default/management/v1/operations/rebalances;
> },
> "operationStart": "2020-02-25T18:53:34.058Z",
> "operationEnd": "2020-02-25T18:53:34.063Z",
> "operationId": "15dfe6ef-acaf-4a45-9b55-1d855a977ba8",
> "operation": {
> "simulate": false
> },
> "operationResult": {
> "statusMessage": "Distributed system has no regions that can be
> rebalanced.",
> "success": true
> }
> },
> {
> "statusCode": "OK",
> "links": {
> "self":
> "http://geodecluster-sample-locator.default/management/v1/operations/rebalances/8218ce0d-e3b8-4c49-b925-665a28e821c3;,
> "list":
> "http://geodecluster-sample-locator.default/management/v1/operations/rebalances;
> },
> "operationStart": "2020-02-25T18:53:45.650Z",
> "operationEnd": "2020-02-25T18:53:45.654Z",
> "operationId": "8218ce0d-e3b8-4c49-b925-665a28e821c3",
> "operation": {
> "simulate": false
> },
> "operationResult": {
> "statusMessage": "Distributed system has no regions that can be
> rebalanced.",
> "success": false
> }
> }
> ],
> "statusCode": "OK"
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7135) Tomcat8SessionsDUnitTest > testSessionExpiration1 FAILED
[
https://issues.apache.org/jira/browse/GEODE-7135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17051476#comment-17051476
]
Mark Hanson commented on GEODE-7135:
More mass-test-run failures 3-4-2020
{noformat}
testSessionPersists1
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/893
testCommitSessionValveInvalidSession
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/785
{noformat}
> Tomcat8SessionsDUnitTest > testSessionExpiration1 FAILED
>
>
> Key: GEODE-7135
> URL: https://issues.apache.org/jira/browse/GEODE-7135
> Project: Geode
> Issue Type: Bug
>Reporter: Murtuza Boxwala
>Priority: Major
> Labels: flaky
>
> {code:java}
> org.apache.geode.modules.session.Tomcat8SessionsDUnitTest >
> testSessionExpiration1 FAILED
> java.net.ConnectException: Connection refused (Connection refused)
> Caused by:
> java.net.ConnectException: Connection refused (Connection refused)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-6903) CI Failure: GemFireTransactionDataSourceIntegrationTest.testExceptionHandlingGetConnection failed with Assertion
[
https://issues.apache.org/jira/browse/GEODE-6903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17051470#comment-17051470
]
Dale Emery commented on GEODE-6903:
---
Failure in CI:
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsCoreIntegrationTestOpenJDK11/builds/827
> CI Failure:
> GemFireTransactionDataSourceIntegrationTest.testExceptionHandlingGetConnection
> failed with Assertion
>
>
> Key: GEODE-6903
> URL: https://issues.apache.org/jira/browse/GEODE-6903
> Project: Geode
> Issue Type: Bug
> Components: transactions
>Reporter: Eric Shu
>Priority: Major
> Labels: flaky
>
> {noformat}
> org.apache.geode.internal.datasource.GemFireTransactionDataSourceIntegrationTest
> > testExceptionHandlingGetConnection FAILED
> org.junit.ComparisonFailure: expected:<[0]> but was:<[2]>
> at sun.reflect.GeneratedConstructorAccessor26.newInstance(Unknown
> Source)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.internal.datasource.GemFireTransactionDataSourceIntegrationTest.testExceptionHandlingGetConnection(GemFireTransactionDataSourceIntegrationTest.java:141)
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.10.0-SNAPSHOT.0399/test-results/integrationTest/1561170841/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.10.0-SNAPSHOT.0399/test-artifacts/1561170841/integrationtestfiles-OpenJDK8-1.10.0-SNAPSHOT.0399.tgz
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-7664) CI Failure: ClientClusterManagementServiceDUnitTest > deleteRegionOnSpecificGroup
[
https://issues.apache.org/jira/browse/GEODE-7664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Hanson updated GEODE-7664:
---
Labels: (was: flaky)
> CI Failure: ClientClusterManagementServiceDUnitTest >
> deleteRegionOnSpecificGroup
> -
>
> Key: GEODE-7664
> URL: https://issues.apache.org/jira/browse/GEODE-7664
> Project: Geode
> Issue Type: Bug
>Reporter: Ivan Godwin
>Assignee: Jinmei Liao
>Priority: Major
>
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/1454]
>
> {code:java}
> org.apache.geode.management.client.ClientClusterManagementServiceDUnitTest >
> deleteRegionOnSpecificGroup FAILEDjava.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 1874 [error 2020/01/09 18:52:37.224 GMT
> tid=353]
> org.apache.geode.internal.cache.DistributedRegion[path='/region2';scope=DISTRIBUTED_ACK';dataPolicy=REPLICATE;
> concurrencyChecksEnabled]
> org.apache.geode.cache.RegionDestroyedException:org.apache.geode.internal.cache.DistributedRegion[path='/region2';scope=DISTRIBUTED_ACK';dataPolicy=REPLICATE;
> concurrencyChecksEnabled]
> at
> org.apache.geode.internal.cache.LocalRegion.checkRegionDestroyed(LocalRegion.java:7296)
> at
> org.apache.geode.internal.cache.LocalRegion.checkReadiness(LocalRegion.java:2750)
> at
> org.apache.geode.internal.cache.LocalRegion.size(LocalRegion.java:8256)
> at
> org.apache.geode.management.internal.configuration.realizers.RegionConfigRealizer.get(RegionConfigRealizer.java:307)
> at
> org.apache.geode.management.internal.configuration.realizers.RegionConfigRealizer.get(RegionConfigRealizer.java:48)
>
> at
> org.apache.geode.management.internal.configuration.realizers.ConfigurationRealizer.exists(ConfigurationRealizer.java:35)
> at
> org.apache.geode.management.internal.functions.CacheRealizationFunction.executeUpdate(CacheRealizationFunction.java:130)
> at
> org.apache.geode.management.internal.functions.CacheRealizationFunction.execute(CacheRealizationFunction.java:79)
> at
> org.apache.geode.internal.cache.MemberFunctionStreamingMessage.process(MemberFunctionStreamingMessage.java:201)
> at
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:394)
>
> at
> org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:458)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> org.apache.geode.distributed.internal.ClusterOperationExecutors.runUntilShutdown(ClusterOperationExecutors.java:449)
> at
> org.apache.geode.distributed.internal.ClusterOperationExecutors.doFunctionExecutionThread(ClusterOperationExecutors.java:379)
> at
> org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:119)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-7843) CI test failures in HashesIntegrationTest
Jens Deppe created GEODE-7843:
-
Summary: CI test failures in HashesIntegrationTest
Key: GEODE-7843
URL: https://issues.apache.org/jira/browse/GEODE-7843
Project: Geode
Issue Type: Bug
Components: redis
Reporter: Jens Deppe
Failing intermittently with:
{noformat}
org.apache.geode.redis.HashesIntegrationTest > testConcurrentHSetNX FAILED
java.lang.AssertionError:
Expecting:
<0>
to be greater than:
<0>
at
org.apache.geode.redis.HashesIntegrationTest.testConcurrentHSetNX(HashesIntegrationTest.java:549)
{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7664) CI Failure: ClientClusterManagementServiceDUnitTest > deleteRegionOnSpecificGroup
[
https://issues.apache.org/jira/browse/GEODE-7664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17051467#comment-17051467
]
Mark Hanson commented on GEODE-7664:
more mass-test-run failures on 3-4-2020
{noformat}
createAndDeleteRegion
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/917
deleteRegionOnSpecificGroup
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/958
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/830
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/775
{noformat}
> CI Failure: ClientClusterManagementServiceDUnitTest >
> deleteRegionOnSpecificGroup
> -
>
> Key: GEODE-7664
> URL: https://issues.apache.org/jira/browse/GEODE-7664
> Project: Geode
> Issue Type: Bug
>Reporter: Ivan Godwin
>Assignee: Jinmei Liao
>Priority: Major
> Labels: flaky
>
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/1454]
>
> {code:java}
> org.apache.geode.management.client.ClientClusterManagementServiceDUnitTest >
> deleteRegionOnSpecificGroup FAILEDjava.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 1874 [error 2020/01/09 18:52:37.224 GMT
> tid=353]
> org.apache.geode.internal.cache.DistributedRegion[path='/region2';scope=DISTRIBUTED_ACK';dataPolicy=REPLICATE;
> concurrencyChecksEnabled]
> org.apache.geode.cache.RegionDestroyedException:org.apache.geode.internal.cache.DistributedRegion[path='/region2';scope=DISTRIBUTED_ACK';dataPolicy=REPLICATE;
> concurrencyChecksEnabled]
> at
> org.apache.geode.internal.cache.LocalRegion.checkRegionDestroyed(LocalRegion.java:7296)
> at
> org.apache.geode.internal.cache.LocalRegion.checkReadiness(LocalRegion.java:2750)
> at
> org.apache.geode.internal.cache.LocalRegion.size(LocalRegion.java:8256)
> at
> org.apache.geode.management.internal.configuration.realizers.RegionConfigRealizer.get(RegionConfigRealizer.java:307)
> at
> org.apache.geode.management.internal.configuration.realizers.RegionConfigRealizer.get(RegionConfigRealizer.java:48)
>
> at
> org.apache.geode.management.internal.configuration.realizers.ConfigurationRealizer.exists(ConfigurationRealizer.java:35)
> at
> org.apache.geode.management.internal.functions.CacheRealizationFunction.executeUpdate(CacheRealizationFunction.java:130)
> at
> org.apache.geode.management.internal.functions.CacheRealizationFunction.execute(CacheRealizationFunction.java:79)
> at
> org.apache.geode.internal.cache.MemberFunctionStreamingMessage.process(MemberFunctionStreamingMessage.java:201)
> at
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:394)
>
> at
> org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:458)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> org.apache.geode.distributed.internal.ClusterOperationExecutors.runUntilShutdown(ClusterOperationExecutors.java:449)
> at
> org.apache.geode.distributed.internal.ClusterOperationExecutors.doFunctionExecutionThread(ClusterOperationExecutors.java:379)
> at
> org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:119)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-7664) CI Failure: ClientClusterManagementServiceDUnitTest > deleteRegionOnSpecificGroup
[
https://issues.apache.org/jira/browse/GEODE-7664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Hanson updated GEODE-7664:
---
Labels: flaky (was: )
> CI Failure: ClientClusterManagementServiceDUnitTest >
> deleteRegionOnSpecificGroup
> -
>
> Key: GEODE-7664
> URL: https://issues.apache.org/jira/browse/GEODE-7664
> Project: Geode
> Issue Type: Bug
>Reporter: Ivan Godwin
>Assignee: Jinmei Liao
>Priority: Major
> Labels: flaky
>
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/1454]
>
> {code:java}
> org.apache.geode.management.client.ClientClusterManagementServiceDUnitTest >
> deleteRegionOnSpecificGroup FAILEDjava.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 1874 [error 2020/01/09 18:52:37.224 GMT
> tid=353]
> org.apache.geode.internal.cache.DistributedRegion[path='/region2';scope=DISTRIBUTED_ACK';dataPolicy=REPLICATE;
> concurrencyChecksEnabled]
> org.apache.geode.cache.RegionDestroyedException:org.apache.geode.internal.cache.DistributedRegion[path='/region2';scope=DISTRIBUTED_ACK';dataPolicy=REPLICATE;
> concurrencyChecksEnabled]
> at
> org.apache.geode.internal.cache.LocalRegion.checkRegionDestroyed(LocalRegion.java:7296)
> at
> org.apache.geode.internal.cache.LocalRegion.checkReadiness(LocalRegion.java:2750)
> at
> org.apache.geode.internal.cache.LocalRegion.size(LocalRegion.java:8256)
> at
> org.apache.geode.management.internal.configuration.realizers.RegionConfigRealizer.get(RegionConfigRealizer.java:307)
> at
> org.apache.geode.management.internal.configuration.realizers.RegionConfigRealizer.get(RegionConfigRealizer.java:48)
>
> at
> org.apache.geode.management.internal.configuration.realizers.ConfigurationRealizer.exists(ConfigurationRealizer.java:35)
> at
> org.apache.geode.management.internal.functions.CacheRealizationFunction.executeUpdate(CacheRealizationFunction.java:130)
> at
> org.apache.geode.management.internal.functions.CacheRealizationFunction.execute(CacheRealizationFunction.java:79)
> at
> org.apache.geode.internal.cache.MemberFunctionStreamingMessage.process(MemberFunctionStreamingMessage.java:201)
> at
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:394)
>
> at
> org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:458)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> org.apache.geode.distributed.internal.ClusterOperationExecutors.runUntilShutdown(ClusterOperationExecutors.java:449)
> at
> org.apache.geode.distributed.internal.ClusterOperationExecutors.doFunctionExecutionThread(ClusterOperationExecutors.java:379)
> at
> org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:119)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7604) QueryConfigurationServiceConstraintsDistributedTest
[
https://issues.apache.org/jira/browse/GEODE-7604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17051461#comment-17051461
]
Mark Hanson commented on GEODE-7604:
More test failures
{noformat}
cqsShouldSucceedDuringEventProcessingAfterRegionOperationWhenMethodAuthorizerIsChangedAndQueryContainsMethodsAllowedByTheNewAuthorizer(regionShortcut=REPLICATE,
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/965
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/955
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/935
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/925
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/864
{noformat}
> QueryConfigurationServiceConstraintsDistributedTest
> ---
>
> Key: GEODE-7604
> URL: https://issues.apache.org/jira/browse/GEODE-7604
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Mark Hanson
>Assignee: Juan Ramos
>Priority: Major
> Labels: GeodeCommons
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> QueryConfigurationServiceConstraintsDistributedTest had two failures in the
> mass test run...
> [2]
> https://concourse.apachegeode-ci.info/teams/main/pipelines/mhansonp-mhanson-mass-test-ru-main/jobs/DistributedTestOpenJDK8/builds/2252
> [6]
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/mhansonp-mhanson-mass-test-ru-main/jobs/DistributedTestOpenJDK8/builds/2211]
>
> {noformat}
> 01:28:56org.apache.geode.cache.query.internal.QueryConfigurationServiceConstraintsDistributedTest
> > [2]
> cqsShouldSucceedDuringEventProcessingAfterRegionOperationWhenMethodAuthorizerIsChangedAndQueryContainsMethodsAllowedByTheNewAuthorizer(RegionType:REPLICATE;Operation:CREATE,ExecuteWithInitialResults:true)
> FAILED
> 01:28:56org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.cache.query.internal.QueryConfigurationServiceConstraintsDistributedTest$$Lambda$57/2082907347.run
> in VM 2 running on Host 8cbcba2ac2b2 with 4 VMs
> 01:28:56at
> org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610)
> 01:28:56at org.apache.geode.test.dunit.VM.invoke(VM.java:437)
> 01:28:56at
> org.apache.geode.test.junit.rules.VMProvider.invoke(VMProvider.java:94)
> 01:28:56at
> org.apache.geode.cache.query.internal.QueryConfigurationServiceConstraintsDistributedTest.cqsShouldSucceedDuringEventProcessingAfterRegionOperationWhenMethodAuthorizerIsChangedAndQueryContainsMethodsAllowedByTheNewAuthorizer(QueryConfigurationServiceConstraintsDistributedTest.java:260)
> 01:28:56
> 01:28:56Caused by:
> 01:28:56org.awaitility.core.ConditionTimeoutException: Assertion
> condition defined as a
> org.apache.geode.cache.query.internal.QueryConfigurationServiceConstraintsDistributedTest
> expected:<[7]> but was:<[4]> within 300 seconds.
> 01:28:56at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:145)
> 01:28:56at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:122)
> 01:28:56at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:32)
> 01:28:56at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:902)
> 01:28:56at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:723)
> 01:28:56at
> org.apache.geode.cache.query.internal.QueryConfigurationServiceConstraintsDistributedTest.lambda$cqsShouldSucceedDuringEventProcessingAfterRegionOperationWhenMethodAuthorizerIsChangedAndQueryContainsMethodsAllowedByTheNewAuthorizer$868d1d80$1(QueryConfigurationServiceConstraintsDistributedTest.java:264)
> 01:28:56
> 01:28:56Caused by:
> 01:28:56org.junit.ComparisonFailure: expected:<[7]> but was:<[4]>
> 01:28:56at
> sun.reflect.GeneratedConstructorAccessor207.newInstance(Unknown Source)
> 01:28:56at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> 01:28:56at
> org.apache.geode.cache.query.internal.QueryConfigurationServiceConstraintsDistributedTest.lambda$null$13(QueryConfigurationServiceConstraintsDistributedTest.java:266)
> 02:03:51
> 02:03:51679 tests completed, 1 failed, 39 skipped {noformat}
>
>
> {noformat}
>
[jira] [Commented] (GEODE-7821) DestroyRegionDuringGIIDistributedTest > testNBRegionInvalidationDuringGetInitialImage_HEAP_DISTRIBUTED_ACK_COMPRESSION FAILED
[
https://issues.apache.org/jira/browse/GEODE-7821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17051459#comment-17051459
]
Mark Hanson commented on GEODE-7821:
More mass-test-run failures 3-4-2020
{noformat}
testNBRegionInvalidationDuringGetInitialImage_HEAP_DISTRIBUTED_ACK_COMPRESSION
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/905
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/851
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/810
{noformat}
> DestroyRegionDuringGIIDistributedTest >
> testNBRegionInvalidationDuringGetInitialImage_HEAP_DISTRIBUTED_ACK_COMPRESSION
> FAILED
> -
>
> Key: GEODE-7821
> URL: https://issues.apache.org/jira/browse/GEODE-7821
> Project: Geode
> Issue Type: Bug
> Components: core, tests
>Affects Versions: 1.13.0
>Reporter: Joris Melchior
>Assignee: Mark Hanson
>Priority: Major
> Labels: flaky
>
> Seen this fail in a couple of places. Failures do not seem to have a direct
> relation to the pull request for the job.
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/1581
> org.apache.geode.internal.cache.DestroyRegionDuringGIIDistributedTest >
> testNBRegionInvalidationDuringGetInitialImage_HEAP_DISTRIBUTED_ACK_COMPRESSION
> FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.DestroyRegionDuringGIIDistributedTest$$Lambda$179/0x000840c73840.run
> in VM 2 running on Host 8f4bff2410d5 with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:437)
> at
> org.apache.geode.internal.cache.DestroyRegionDuringGIIDistributedTest.testNBRegionInvalidationDuringGetInitialImage(DestroyRegionDuringGIIDistributedTest.java:414)
> Caused by:
> org.junit.ComparisonFailure: expected: but was:<[66, 66, 66,
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66,
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66,
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66,
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66,
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66,
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66,
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66,
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66,
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66,
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66,
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66,
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66,
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66,
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66,
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66,
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66,
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66,
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66,
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66,
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66,
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66,
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66,
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66,
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66,
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66,
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66,
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66,
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66,
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66,
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66,
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66,
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66,
> 66, 66, 66, 66, 66, 66,
[jira] [Commented] (GEODE-7710) JMXMBeanReconnectDUnitTest fails intermittently because one locator is missing the LockServiceMXBean
[
https://issues.apache.org/jira/browse/GEODE-7710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17051457#comment-17051457
]
Mark Hanson commented on GEODE-7710:
More failures in the 3-4-2020 mass-test-run
{noformat}
serverMXBeansAreRestoredOnBothLocatorsAfterCrashedServerReturns
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/823
locatorHasMemberTypeMXBeansForBothLocators
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/965
locatorHasMemberTypeMXBeansForBothLocators
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/872
serverMXBeansOnServerAreUnaffectedByLocatorCrash
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/861
locatorMXBeansOnOtherLocatorAreRestoredAfterCrashedLocatorReturns
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/809
{noformat}
> JMXMBeanReconnectDUnitTest fails intermittently because one locator is
> missing the LockServiceMXBean
>
>
> Key: GEODE-7710
> URL: https://issues.apache.org/jira/browse/GEODE-7710
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Labels: flaky
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> Multiple tests in JMXMBeanReconnectDUnitTest may fail an await due to one of
> the locators missing the LockServiceMXBean for the cluster config service.
> {noformat}
> but could not find:
>
> <[GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator1]>
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7830) Management REST API rebalance endpoints return confusing operationResults
[
https://issues.apache.org/jira/browse/GEODE-7830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17051447#comment-17051447
]
Darrel Schneider commented on GEODE-7830:
-
The danger of turning these "noop" rebalances into success is that it could
have been a "noop" do to operator error. For example they may have attempted
the rebalance too soon, before their servers and/or regions were brought
online. In that case I think it would be better for the user to see an error. I
agree that you should be seeing a consistent response and that this part of the
bug should be fixed.
> Management REST API rebalance endpoints return confusing operationResults
> -
>
> Key: GEODE-7830
> URL: https://issues.apache.org/jira/browse/GEODE-7830
> Project: Geode
> Issue Type: Bug
> Components: management
>Reporter: Aaron Lindsey
>Assignee: Darrel Schneider
>Priority: Major
>
> We observed odd behavior regarding the operationResult object returned in the
> rebalance API:
> # It contains success=false if the cluster has no regions or has no servers.
> This is confusing because the rebalance didn't fail — it just didn't have
> anything to rebalance so it was basically a no-op. As a consumer of this API,
> I need to be able to distinguish between "real" failures and this "no-op"
> failure, and I should not have to write code to parse the "statusMessage" to
> do that.
> # Sometimes, success=true and other times success=false for the same
> statusMessage: "Distributed system has no regions that can be rebalanced."
> This is confusing because I don't know why it sometimes considers this a
> failure and other times considers it a success. If #1 above is fixed, then
> this would not be an issue because it would always return success=true for
> this particular statusMessage.
> Here is an example of two confusing operationResults we observed:
> {code:json}
> {
> "result": [
> {
> "statusCode": "OK",
> "links": {
> "self":
> "http://geodecluster-sample-locator.default/management/v1/operations/rebalances/15dfe6ef-acaf-4a45-9b55-1d855a977ba8;,
> "list":
> "http://geodecluster-sample-locator.default/management/v1/operations/rebalances;
> },
> "operationStart": "2020-02-25T18:53:34.058Z",
> "operationEnd": "2020-02-25T18:53:34.063Z",
> "operationId": "15dfe6ef-acaf-4a45-9b55-1d855a977ba8",
> "operation": {
> "simulate": false
> },
> "operationResult": {
> "statusMessage": "Distributed system has no regions that can be
> rebalanced.",
> "success": true
> }
> },
> {
> "statusCode": "OK",
> "links": {
> "self":
> "http://geodecluster-sample-locator.default/management/v1/operations/rebalances/8218ce0d-e3b8-4c49-b925-665a28e821c3;,
> "list":
> "http://geodecluster-sample-locator.default/management/v1/operations/rebalances;
> },
> "operationStart": "2020-02-25T18:53:45.650Z",
> "operationEnd": "2020-02-25T18:53:45.654Z",
> "operationId": "8218ce0d-e3b8-4c49-b925-665a28e821c3",
> "operation": {
> "simulate": false
> },
> "operationResult": {
> "statusMessage": "Distributed system has no regions that can be
> rebalanced.",
> "success": false
> }
> }
> ],
> "statusCode": "OK"
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-7830) Management REST API rebalance endpoints return confusing operationResults
[
https://issues.apache.org/jira/browse/GEODE-7830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darrel Schneider reassigned GEODE-7830:
---
Assignee: Darrel Schneider
> Management REST API rebalance endpoints return confusing operationResults
> -
>
> Key: GEODE-7830
> URL: https://issues.apache.org/jira/browse/GEODE-7830
> Project: Geode
> Issue Type: Bug
> Components: management
>Reporter: Aaron Lindsey
>Assignee: Darrel Schneider
>Priority: Major
>
> We observed odd behavior regarding the operationResult object returned in the
> rebalance API:
> # It contains success=false if the cluster has no regions or has no servers.
> This is confusing because the rebalance didn't fail — it just didn't have
> anything to rebalance so it was basically a no-op. As a consumer of this API,
> I need to be able to distinguish between "real" failures and this "no-op"
> failure, and I should not have to write code to parse the "statusMessage" to
> do that.
> # Sometimes, success=true and other times success=false for the same
> statusMessage: "Distributed system has no regions that can be rebalanced."
> This is confusing because I don't know why it sometimes considers this a
> failure and other times considers it a success. If #1 above is fixed, then
> this would not be an issue because it would always return success=true for
> this particular statusMessage.
> Here is an example of two confusing operationResults we observed:
> {code:json}
> {
> "result": [
> {
> "statusCode": "OK",
> "links": {
> "self":
> "http://geodecluster-sample-locator.default/management/v1/operations/rebalances/15dfe6ef-acaf-4a45-9b55-1d855a977ba8;,
> "list":
> "http://geodecluster-sample-locator.default/management/v1/operations/rebalances;
> },
> "operationStart": "2020-02-25T18:53:34.058Z",
> "operationEnd": "2020-02-25T18:53:34.063Z",
> "operationId": "15dfe6ef-acaf-4a45-9b55-1d855a977ba8",
> "operation": {
> "simulate": false
> },
> "operationResult": {
> "statusMessage": "Distributed system has no regions that can be
> rebalanced.",
> "success": true
> }
> },
> {
> "statusCode": "OK",
> "links": {
> "self":
> "http://geodecluster-sample-locator.default/management/v1/operations/rebalances/8218ce0d-e3b8-4c49-b925-665a28e821c3;,
> "list":
> "http://geodecluster-sample-locator.default/management/v1/operations/rebalances;
> },
> "operationStart": "2020-02-25T18:53:45.650Z",
> "operationEnd": "2020-02-25T18:53:45.654Z",
> "operationId": "8218ce0d-e3b8-4c49-b925-665a28e821c3",
> "operation": {
> "simulate": false
> },
> "operationResult": {
> "statusMessage": "Distributed system has no regions that can be
> rebalanced.",
> "success": false
> }
> }
> ],
> "statusCode": "OK"
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7421) Ability: can deploy jar by REST API for Management
[ https://issues.apache.org/jira/browse/GEODE-7421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17051350#comment-17051350 ] ASF subversion and git services commented on GEODE-7421: Commit f15bbc7839e1fd6eba8c28be1c3145dd86e895e6 in geode's branch refs/heads/develop from Jinmei Liao [ https://gitbox.apache.org/repos/asf?p=geode.git;h=f15bbc7 ] GEODE-7421: use RequestParam instead of RequestPart to be compatible with all rest client (#4766) > Ability: can deploy jar by REST API for Management > -- > > Key: GEODE-7421 > URL: https://issues.apache.org/jira/browse/GEODE-7421 > Project: Geode > Issue Type: New Feature > Components: management, rest (admin) >Reporter: Gang Yan >Priority: Major > Fix For: 1.13.0 > > Time Spent: 5h 10m > Remaining Estimate: 0h > > # WHAT > 1. can deploy jar file by REST API > 2. from feature point , it will cover current 'gfsh deploy' > 3. if two files have same file name, the later wins > 4. can recognize version pattern. "filename-version[-label].jar" . > filename=[a-zA-Z/-]+, not single "-", not end with "-" > version=[0-9/.]*, not single ".", not end with "." > label=[a-zA-Z0-9]* > such as: > -is a later version of > , will deploy. > -is a same version of > , the later wins > -is a same version of > , the later wins > -is an earlier version of > , will block it. > 5. if there is a version part in the file name, we will deploy them > without append "#1" part to the file name > 6. can accept "group" -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7752) Update ConfigurationServiceBuilder to be more intuitive
[ https://issues.apache.org/jira/browse/GEODE-7752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17051348#comment-17051348 ] ASF subversion and git services commented on GEODE-7752: Commit b3af99edd964eea8a3a02a0298db47a8ea3e9d67 in geode's branch refs/heads/develop from Jinmei Liao [ https://gitbox.apache.org/repos/asf?p=geode.git;h=b3af99e ] GEODE-7752: Delete the extra GeodeClusterManagementServiceBuilder (#4760) > Update ConfigurationServiceBuilder to be more intuitive > --- > > Key: GEODE-7752 > URL: https://issues.apache.org/jira/browse/GEODE-7752 > Project: Geode > Issue Type: Improvement > Components: configuration >Reporter: Udo Kohlmeyer >Assignee: Udo Kohlmeyer >Priority: Major > Fix For: 1.12.0, 1.13.0 > > Time Spent: 3h > Remaining Estimate: 0h > > With the introduction of ClusterManagementServiceBuilder, an inadvertent > confusing configuration manner was introduced. > In the Builder pattern, the setter methods are optional and required fields > are either added on the constructor or build method. > The current ClusterManangementServiceBuilder introduced the notion of > required optionality. Where you had to pick at least one of the setters. > To fix this, I removed `setConnectionConfig` which is really only required > for the Transport and removed that option. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-7832) Remove connection "send semaphores" from DirectChannel
[ https://issues.apache.org/jira/browse/GEODE-7832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juan Ramos resolved GEODE-7832. --- Fix Version/s: 1.13.0 Resolution: Fixed > Remove connection "send semaphores" from DirectChannel > -- > > Key: GEODE-7832 > URL: https://issues.apache.org/jira/browse/GEODE-7832 > Project: Geode > Issue Type: Improvement > Components: membership >Reporter: Bruce J Schuchardt >Assignee: Juan Ramos >Priority: Major > Labels: GeodeCommons > Fix For: 1.13.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Remove the acquiredSendSemaphore/acquireGroupSendSemaphore and related > methods from DirectChannel/TCPConduit code. Connection.isReaderThread() and > associated makeReaderThread() methods can also be deleted because they're > only used by the semaphore code. > These semaphores only constrain messaging if you set a couple of undocumented > system properties, p2p.maxGroupSenders and p2p.maxConnectionSenders to some > small value. These are (MAX_INT / 2) by default. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7832) Remove connection "send semaphores" from DirectChannel
[ https://issues.apache.org/jira/browse/GEODE-7832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17051026#comment-17051026 ] ASF subversion and git services commented on GEODE-7832: Commit 2a3e09f2da4793d08d1124b5d5e656285295937d in geode's branch refs/heads/develop from Juan José Ramos [ https://gitbox.apache.org/repos/asf?p=geode.git;h=2a3e09f ] GEODE-7832: Remove Connection Semaphores (#4754) Removed the semaphores and related methods from DirectChannel and Connection classes. They were used to constrain messaging when some undocumented system properties were set. > Remove connection "send semaphores" from DirectChannel > -- > > Key: GEODE-7832 > URL: https://issues.apache.org/jira/browse/GEODE-7832 > Project: Geode > Issue Type: Improvement > Components: membership >Reporter: Bruce J Schuchardt >Assignee: Juan Ramos >Priority: Major > Labels: GeodeCommons > Time Spent: 20m > Remaining Estimate: 0h > > Remove the acquiredSendSemaphore/acquireGroupSendSemaphore and related > methods from DirectChannel/TCPConduit code. Connection.isReaderThread() and > associated makeReaderThread() methods can also be deleted because they're > only used by the semaphore code. > These semaphores only constrain messaging if you set a couple of undocumented > system properties, p2p.maxGroupSenders and p2p.maxConnectionSenders to some > small value. These are (MAX_INT / 2) by default. -- This message was sent by Atlassian Jira (v8.3.4#803005)
