[jira] [Commented] (GEODE-7682) Create the java API to clear a PartitionedRegion
[ https://issues.apache.org/jira/browse/GEODE-7682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17053111#comment-17053111 ] ASF subversion and git services commented on GEODE-7682: Commit 43bd36442c0472eb5c139e7aa7dff61fe6425879 in geode's branch refs/heads/feature/GEODE-7665 from Xiaojian Zhou [ https://gitbox.apache.org/repos/asf?p=geode.git;h=43bd364 ] GEODE-7682: add PR.clear API (#4755) * GEODE-7683: introduce BR.cmnClearRegion Co-authored-by: Xiaojian Zhou > Create the java API to clear a PartitionedRegion > > > Key: GEODE-7682 > URL: https://issues.apache.org/jira/browse/GEODE-7682 > Project: Geode > Issue Type: New Feature > Components: regions >Reporter: Nabarun Nag >Priority: Major > Labels: GeodeCommons > Time Spent: 7h 50m > Remaining Estimate: 0h > > This task will just include creating the API which calls the internal > commands to clear the region and send messages to the members hosting the > Partitioned region. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7683) Implement the Bucket Region cmnClearRegion
[ https://issues.apache.org/jira/browse/GEODE-7683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17053112#comment-17053112 ] ASF subversion and git services commented on GEODE-7683: Commit 43bd36442c0472eb5c139e7aa7dff61fe6425879 in geode's branch refs/heads/feature/GEODE-7665 from Xiaojian Zhou [ https://gitbox.apache.org/repos/asf?p=geode.git;h=43bd364 ] GEODE-7682: add PR.clear API (#4755) * GEODE-7683: introduce BR.cmnClearRegion Co-authored-by: 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-7682) Create the java API to clear a PartitionedRegion
[ https://issues.apache.org/jira/browse/GEODE-7682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17052755#comment-17052755 ] ASF subversion and git services commented on GEODE-7682: Commit 4c99aa105a1e4a791caed869daaa40ff7d179e1c in geode's branch refs/heads/feature/GEODE-7682-2 from Xiaojian Zhou [ https://gitbox.apache.org/repos/asf?p=geode.git;h=4c99aa1 ] Merge branch 'feature/GEODE-7665' into feature/GEODE-7682-2 > Create the java API to clear a PartitionedRegion > > > Key: GEODE-7682 > URL: https://issues.apache.org/jira/browse/GEODE-7682 > Project: Geode > Issue Type: New Feature > Components: regions >Reporter: Nabarun Nag >Priority: Major > Labels: GeodeCommons > Time Spent: 7h 40m > Remaining Estimate: 0h > > This task will just include creating the API which calls the internal > commands to clear the region and send messages to the members hosting the > Partitioned 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=17052746#comment-17052746
]
ASF subversion and git services commented on GEODE-7842:
Commit a5c8e2bc0e41bf591c24e44e1cbfe48c3ca59e7b in geode's branch
refs/heads/feature/GEODE-7682-2 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] [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=17052743#comment-17052743 ] ASF subversion and git services commented on GEODE-7832: Commit 2a3e09f2da4793d08d1124b5d5e656285295937d in geode's branch refs/heads/feature/GEODE-7682-2 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 > 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-7841) Add benchmarking scripts for Geode-Redis module
[ https://issues.apache.org/jira/browse/GEODE-7841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17052751#comment-17052751 ] ASF subversion and git services commented on GEODE-7841: Commit b57456e2cd9f179cf018adaf676a9b78bdc98270 in geode's branch refs/heads/feature/GEODE-7682-2 from Jens Deppe [ https://gitbox.apache.org/repos/asf?p=geode.git;h=b57456e ] GEODE-7841 Add benchmarking scripts for Geode-Redis module (#4763) > Add benchmarking scripts for Geode-Redis module > --- > > Key: GEODE-7841 > URL: https://issues.apache.org/jira/browse/GEODE-7841 > Project: Geode > Issue Type: New Feature > Components: benchmarks, redis >Reporter: Raymond Ingles >Assignee: Jens Deppe >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > Add the following scripts to the Geode-Redis module, in the "performanceTest" > directory: > * aggregator.sh runs the actual tests > * benchmark.sh handles validating the redis server (e.g. starting and > stopping Geode Redis if needed), then runs aggregator.sh > * shacompare.sh takes two git SHAs as arguments and runs benchmark.sh on > each of them, generating separate output files for each. -- 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=17052745#comment-17052745 ] ASF subversion and git services commented on GEODE-7421: Commit f15bbc7839e1fd6eba8c28be1c3145dd86e895e6 in geode's branch refs/heads/feature/GEODE-7682-2 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=17052744#comment-17052744 ] ASF subversion and git services commented on GEODE-7752: Commit b3af99edd964eea8a3a02a0298db47a8ea3e9d67 in geode's branch refs/heads/feature/GEODE-7682-2 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] [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=17052749#comment-17052749 ] ASF subversion and git services commented on GEODE-7808: Commit 5c2b959e98a6330ecaeddb4d26e11ea29f7a2d7f in geode's branch refs/heads/feature/GEODE-7682-2 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: 7h > 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-7828) Convert backing store for Redis Hashes and Sets to single regions
[
https://issues.apache.org/jira/browse/GEODE-7828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17052742#comment-17052742
]
ASF subversion and git services commented on GEODE-7828:
Commit 2f6bf013368df5a4b5efe68162a4953f9a88bbf2 in geode's branch
refs/heads/feature/GEODE-7682-2 from Jens Deppe
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=2f6bf01 ]
GEODE-7828: Convert backing store for Redis Hashes and Sets to single regions
(#4745)
* GEODE-7828: Convert backing store for Redis Hashes and Sets to single regions
This PR builds on the work originally submitted by Greg Green in
https://github.com/apache/geode/pull/404. Also acknowledgements to Galen
O'Sullivan for addressing locking issues in that PR.
This commit changes the storage model of Redis hashes and sets from one
region per each Redis key to a single hash region and single set region.
The Redis key is now also the region key and the data is stored in a Map
and Set respectively in the region. Currently, the backing values do not
implement Delta changes, however this will be a future optimization.
This also fixes the inability of Redis keys to contain other characters
commonly used, such as colons (':').
- Add `RedisLockService` which manages a lock per key within a single
JVM. Locks are held in a WeakHasMap to allow for automatic cleanup
(prior PR work, using a pure ConcurrentHashMap, ended up leaking
memory since there is no straight-forward way to clean up unused
keys/locks).
- Add new tests including concurrency tests for hashes and sets
Co-authored-by: Greg Green
Co-authored-by: Ray Ingles
Co-authored-by: Sarah Abbey
Co-authored-by: John Hutchison
Co-authored-by: Murtuza Boxwala
Co-authored-by: Prasath Durairaj
Co-authored-by: Jens Deppe
> Convert backing store for Redis Hashes and Sets to single regions
> -
>
> Key: GEODE-7828
> URL: https://issues.apache.org/jira/browse/GEODE-7828
> Project: Geode
> Issue Type: Improvement
> Components: redis
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
> Fix For: 1.13.0
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Currently the Redis adapter creates separate regions for each new hash or
> set. This can be a significant performance impact when many hashes are being
> created. In addition, hashes are conventionally often named with colons (':')
> in their name - for example {{user:1000}}. This does not work as region names
> cannot contain colons.
> The work here will create a single region for hashes and a single region for
> sets.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7683) Implement the Bucket Region cmnClearRegion
[ https://issues.apache.org/jira/browse/GEODE-7683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17052752#comment-17052752 ] ASF subversion and git services commented on GEODE-7683: Commit ccb543fc2b3911304d15c84cda36b6ede0c2a41b in geode's branch refs/heads/feature/GEODE-7682-2 from zhouxh [ https://gitbox.apache.org/repos/asf?p=geode.git;h=ccb543f ] GEODE-7683: introduce BR.cmnClearRegion Co-authored-by: Xiaojian Zhou GEODE-7684: Create messaging class for PR Clear (#4689) * Added new message class and test Co-authored-by: Benjamin Ross Co-authored-by: Donal Evans > 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-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=17052748#comment-17052748 ] ASF subversion and git services commented on GEODE-7808: Commit 5c2b959e98a6330ecaeddb4d26e11ea29f7a2d7f in geode's branch refs/heads/feature/GEODE-7682-2 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: 7h > 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-7684) Implement the Bucket region clear messages and handling
[ https://issues.apache.org/jira/browse/GEODE-7684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17052753#comment-17052753 ] ASF subversion and git services commented on GEODE-7684: Commit ccb543fc2b3911304d15c84cda36b6ede0c2a41b in geode's branch refs/heads/feature/GEODE-7682-2 from zhouxh [ https://gitbox.apache.org/repos/asf?p=geode.git;h=ccb543f ] GEODE-7683: introduce BR.cmnClearRegion Co-authored-by: Xiaojian Zhou GEODE-7684: Create messaging class for PR Clear (#4689) * Added new message class and test Co-authored-by: Benjamin Ross Co-authored-by: Donal Evans > Implement the Bucket region clear messages and handling > --- > > Key: GEODE-7684 > URL: https://issues.apache.org/jira/browse/GEODE-7684 > Project: Geode > Issue Type: New Feature > Components: regions >Reporter: Nabarun Nag >Priority: Major > Labels: GeodeCommons > Time Spent: 4h 10m > Remaining Estimate: 0h > > Implement the bucket region clear message, and the handling of the message. > Upon receiving this message the bucket region must be cleared. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7828) Convert backing store for Redis Hashes and Sets to single regions
[
https://issues.apache.org/jira/browse/GEODE-7828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17052741#comment-17052741
]
ASF subversion and git services commented on GEODE-7828:
Commit 2f6bf013368df5a4b5efe68162a4953f9a88bbf2 in geode's branch
refs/heads/feature/GEODE-7682-2 from Jens Deppe
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=2f6bf01 ]
GEODE-7828: Convert backing store for Redis Hashes and Sets to single regions
(#4745)
* GEODE-7828: Convert backing store for Redis Hashes and Sets to single regions
This PR builds on the work originally submitted by Greg Green in
https://github.com/apache/geode/pull/404. Also acknowledgements to Galen
O'Sullivan for addressing locking issues in that PR.
This commit changes the storage model of Redis hashes and sets from one
region per each Redis key to a single hash region and single set region.
The Redis key is now also the region key and the data is stored in a Map
and Set respectively in the region. Currently, the backing values do not
implement Delta changes, however this will be a future optimization.
This also fixes the inability of Redis keys to contain other characters
commonly used, such as colons (':').
- Add `RedisLockService` which manages a lock per key within a single
JVM. Locks are held in a WeakHasMap to allow for automatic cleanup
(prior PR work, using a pure ConcurrentHashMap, ended up leaking
memory since there is no straight-forward way to clean up unused
keys/locks).
- Add new tests including concurrency tests for hashes and sets
Co-authored-by: Greg Green
Co-authored-by: Ray Ingles
Co-authored-by: Sarah Abbey
Co-authored-by: John Hutchison
Co-authored-by: Murtuza Boxwala
Co-authored-by: Prasath Durairaj
Co-authored-by: Jens Deppe
> Convert backing store for Redis Hashes and Sets to single regions
> -
>
> Key: GEODE-7828
> URL: https://issues.apache.org/jira/browse/GEODE-7828
> Project: Geode
> Issue Type: Improvement
> Components: redis
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
> Fix For: 1.13.0
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Currently the Redis adapter creates separate regions for each new hash or
> set. This can be a significant performance impact when many hashes are being
> created. In addition, hashes are conventionally often named with colons (':')
> in their name - for example {{user:1000}}. This does not work as region names
> cannot contain colons.
> The work here will create a single region for hashes and a single region for
> sets.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7665) Ability to clear a Partitioned Region
[ https://issues.apache.org/jira/browse/GEODE-7665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17052754#comment-17052754 ] ASF subversion and git services commented on GEODE-7665: Commit 4c99aa105a1e4a791caed869daaa40ff7d179e1c in geode's branch refs/heads/feature/GEODE-7682-2 from Xiaojian Zhou [ https://gitbox.apache.org/repos/asf?p=geode.git;h=4c99aa1 ] Merge branch 'feature/GEODE-7665' into feature/GEODE-7682-2 > Ability to clear a Partitioned Region > - > > Key: GEODE-7665 > URL: https://issues.apache.org/jira/browse/GEODE-7665 > Project: Geode > Issue Type: New Feature > Components: regions >Reporter: Nabarun Nag >Priority: Major > Labels: GeodeCommons > > With the successful voting of the RFC for implementing clear operation on > Partitioned Region > [[https://cwiki.apache.org/confluence/display/GEODE/Support+for+clear+operation+on+partitioned+region]] > we are starting the code implementation. > > Details of the implementation and design are maintained in the RFC document > mentioned above. This ticket will act as a parent Jira under which all the > subsequent sub-JIRAs will be created. This ticket will be closed once all the > sub jiras are implemented. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7840) Redis pub/sub does not handle binary messages correctly
[ https://issues.apache.org/jira/browse/GEODE-7840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17052750#comment-17052750 ] ASF subversion and git services commented on GEODE-7840: Commit 838e0704ed03b0008b4b62f10269b7eed1bd7e18 in geode's branch refs/heads/feature/GEODE-7682-2 from Jens Deppe [ https://gitbox.apache.org/repos/asf?p=geode.git;h=838e070 ] GEODE-7840: Redis pub/sub does not handle binary messages correctly (#4762) > Redis pub/sub does not handle binary messages correctly > --- > > Key: GEODE-7840 > URL: https://issues.apache.org/jira/browse/GEODE-7840 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > The new pub/sub functionality currently only considers published messages to > be actual strings and does not account for them being binary data. This > results in messages being corrupted since they end up being UTF-8 encoded. -- 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=17052747#comment-17052747 ] ASF subversion and git services commented on GEODE-7808: Commit 5c2b959e98a6330ecaeddb4d26e11ea29f7a2d7f in geode's branch refs/heads/feature/GEODE-7682-2 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: 7h > 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-7642) Reduce compiler warnings
[
https://issues.apache.org/jira/browse/GEODE-7642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacob Barrett reassigned GEODE-7642:
Assignee: Jacob Barrett
> Reduce compiler warnings
>
>
> Key: GEODE-7642
> URL: https://issues.apache.org/jira/browse/GEODE-7642
> Project: Geode
> Issue Type: Improvement
> Components: management
>Reporter: Jinmei Liao
>Assignee: Jacob Barrett
>Priority: Major
>
> /Users/echobravo/Developer/gemfire/geode/geode-core/src/main/java/org/apache/geode/management/internal/BlockMBeanCreationController.java:19:
> warning: MBeanServerAccessController is internal proprietary API and may be
> removed in a future release
> import com.sun.jmx.remote.security.MBeanServerAccessController;
> ^
> warning: unknown enum constant When.MAYBE
> reason: class file for javax.annotation.meta.When not found
> warning: unknown enum constant AccessMode.READ_ONLY
> reason: class file for io.swagger.annotations.ApiModelProperty$AccessMode
> not found
> warning: unknown enum constant AccessMode.READ_ONLY
> /Users/echobravo/Developer/gemfire/geode/geode-core/src/main/java/org/apache/geode/management/internal/BlockMBeanCreationController.java:19:
> warning: MBeanServerAccessController is internal proprietary API and may be
> removed in a future release
> import com.sun.jmx.remote.security.MBeanServerAccessController;
> ^
> warning: unknown enum constant When.MAYBE
> reason: class file for javax.annotation.meta.When not found
> warning: unknown enum constant AccessMode.READ_ONLY
> reason: class file for io.swagger.annotations.ApiModelProperty$AccessMode
> not found
> warning: unknown enum constant AccessMode.READ_ONLY
> /Users/echobravo/Developer/gemfire/geode/geode-core/src/main/java/org/apache/geode/management/internal/BlockMBeanCreationController.java:19:
> warning: MBeanServerAccessController is internal proprietary API and may be
> removed in a future release
> import com.sun.jmx.remote.security.MBeanServerAccessController;
> ^
> warning: unknown enum constant When.MAYBE
> reason: class file for javax.annotation.meta.When not found
> warning: unknown enum constant AccessMode.READ_ONLY
> reason: class file for io.swagger.annotations.ApiModelProperty$AccessMode
> not found
> warning: unknown enum constant AccessMode.READ_ONLY
> /Users/echobravo/Developer/gemfire/geode/geode-core/src/main/java/org/apache/geode/management/internal/BlockMBeanCreationController.java:21:
> warning: MBeanServerAccessController is internal proprietary API and may be
> removed in a future release
> public class BlockMBeanCreationController extends MBeanServerAccessController
> {
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7684) Implement the Bucket region clear messages and handling
[ https://issues.apache.org/jira/browse/GEODE-7684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17052663#comment-17052663 ] ASF subversion and git services commented on GEODE-7684: Commit ccb543fc2b3911304d15c84cda36b6ede0c2a41b in geode's branch refs/heads/feature/GEODE-7665 from zhouxh [ https://gitbox.apache.org/repos/asf?p=geode.git;h=ccb543f ] GEODE-7683: introduce BR.cmnClearRegion Co-authored-by: Xiaojian Zhou GEODE-7684: Create messaging class for PR Clear (#4689) * Added new message class and test Co-authored-by: Benjamin Ross Co-authored-by: Donal Evans > Implement the Bucket region clear messages and handling > --- > > Key: GEODE-7684 > URL: https://issues.apache.org/jira/browse/GEODE-7684 > Project: Geode > Issue Type: New Feature > Components: regions >Reporter: Nabarun Nag >Priority: Major > Labels: GeodeCommons > Time Spent: 4h 10m > Remaining Estimate: 0h > > Implement the bucket region clear message, and the handling of the message. > Upon receiving this message the bucket region must be cleared. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7840) Redis pub/sub does not handle binary messages correctly
[ https://issues.apache.org/jira/browse/GEODE-7840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17052660#comment-17052660 ] ASF subversion and git services commented on GEODE-7840: Commit 838e0704ed03b0008b4b62f10269b7eed1bd7e18 in geode's branch refs/heads/feature/GEODE-7665 from Jens Deppe [ https://gitbox.apache.org/repos/asf?p=geode.git;h=838e070 ] GEODE-7840: Redis pub/sub does not handle binary messages correctly (#4762) > Redis pub/sub does not handle binary messages correctly > --- > > Key: GEODE-7840 > URL: https://issues.apache.org/jira/browse/GEODE-7840 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > The new pub/sub functionality currently only considers published messages to > be actual strings and does not account for them being binary data. This > results in messages being corrupted since they end up being UTF-8 encoded. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7841) Add benchmarking scripts for Geode-Redis module
[ https://issues.apache.org/jira/browse/GEODE-7841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17052661#comment-17052661 ] ASF subversion and git services commented on GEODE-7841: Commit b57456e2cd9f179cf018adaf676a9b78bdc98270 in geode's branch refs/heads/feature/GEODE-7665 from Jens Deppe [ https://gitbox.apache.org/repos/asf?p=geode.git;h=b57456e ] GEODE-7841 Add benchmarking scripts for Geode-Redis module (#4763) > Add benchmarking scripts for Geode-Redis module > --- > > Key: GEODE-7841 > URL: https://issues.apache.org/jira/browse/GEODE-7841 > Project: Geode > Issue Type: New Feature > Components: benchmarks, redis >Reporter: Raymond Ingles >Assignee: Jens Deppe >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > Add the following scripts to the Geode-Redis module, in the "performanceTest" > directory: > * aggregator.sh runs the actual tests > * benchmark.sh handles validating the redis server (e.g. starting and > stopping Geode Redis if needed), then runs aggregator.sh > * shacompare.sh takes two git SHAs as arguments and runs benchmark.sh on > each of them, generating separate output files for each. -- 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=17052659#comment-17052659 ] ASF subversion and git services commented on GEODE-7808: Commit 5c2b959e98a6330ecaeddb4d26e11ea29f7a2d7f in geode's branch refs/heads/feature/GEODE-7665 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: 7h > 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-7683) Implement the Bucket Region cmnClearRegion
[ https://issues.apache.org/jira/browse/GEODE-7683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17052662#comment-17052662 ] ASF subversion and git services commented on GEODE-7683: Commit ccb543fc2b3911304d15c84cda36b6ede0c2a41b in geode's branch refs/heads/feature/GEODE-7665 from zhouxh [ https://gitbox.apache.org/repos/asf?p=geode.git;h=ccb543f ] GEODE-7683: introduce BR.cmnClearRegion Co-authored-by: Xiaojian Zhou GEODE-7684: Create messaging class for PR Clear (#4689) * Added new message class and test Co-authored-by: Benjamin Ross Co-authored-by: Donal Evans > 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-7752) Update ConfigurationServiceBuilder to be more intuitive
[ https://issues.apache.org/jira/browse/GEODE-7752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17052654#comment-17052654 ] ASF subversion and git services commented on GEODE-7752: Commit b3af99edd964eea8a3a02a0298db47a8ea3e9d67 in geode's branch refs/heads/feature/GEODE-7665 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] [Commented] (GEODE-7842) Improve concurrent region creation
[
https://issues.apache.org/jira/browse/GEODE-7842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17052656#comment-17052656
]
ASF subversion and git services commented on GEODE-7842:
Commit a5c8e2bc0e41bf591c24e44e1cbfe48c3ca59e7b in geode's branch
refs/heads/feature/GEODE-7665 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] [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=17052658#comment-17052658 ] ASF subversion and git services commented on GEODE-7808: Commit 5c2b959e98a6330ecaeddb4d26e11ea29f7a2d7f in geode's branch refs/heads/feature/GEODE-7665 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: 7h > 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-7828) Convert backing store for Redis Hashes and Sets to single regions
[
https://issues.apache.org/jira/browse/GEODE-7828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17052652#comment-17052652
]
ASF subversion and git services commented on GEODE-7828:
Commit 2f6bf013368df5a4b5efe68162a4953f9a88bbf2 in geode's branch
refs/heads/feature/GEODE-7665 from Jens Deppe
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=2f6bf01 ]
GEODE-7828: Convert backing store for Redis Hashes and Sets to single regions
(#4745)
* GEODE-7828: Convert backing store for Redis Hashes and Sets to single regions
This PR builds on the work originally submitted by Greg Green in
https://github.com/apache/geode/pull/404. Also acknowledgements to Galen
O'Sullivan for addressing locking issues in that PR.
This commit changes the storage model of Redis hashes and sets from one
region per each Redis key to a single hash region and single set region.
The Redis key is now also the region key and the data is stored in a Map
and Set respectively in the region. Currently, the backing values do not
implement Delta changes, however this will be a future optimization.
This also fixes the inability of Redis keys to contain other characters
commonly used, such as colons (':').
- Add `RedisLockService` which manages a lock per key within a single
JVM. Locks are held in a WeakHasMap to allow for automatic cleanup
(prior PR work, using a pure ConcurrentHashMap, ended up leaking
memory since there is no straight-forward way to clean up unused
keys/locks).
- Add new tests including concurrency tests for hashes and sets
Co-authored-by: Greg Green
Co-authored-by: Ray Ingles
Co-authored-by: Sarah Abbey
Co-authored-by: John Hutchison
Co-authored-by: Murtuza Boxwala
Co-authored-by: Prasath Durairaj
Co-authored-by: Jens Deppe
> Convert backing store for Redis Hashes and Sets to single regions
> -
>
> Key: GEODE-7828
> URL: https://issues.apache.org/jira/browse/GEODE-7828
> Project: Geode
> Issue Type: Improvement
> Components: redis
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
> Fix For: 1.13.0
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Currently the Redis adapter creates separate regions for each new hash or
> set. This can be a significant performance impact when many hashes are being
> created. In addition, hashes are conventionally often named with colons (':')
> in their name - for example {{user:1000}}. This does not work as region names
> cannot contain colons.
> The work here will create a single region for hashes and a single region for
> sets.
--
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=17052655#comment-17052655 ] ASF subversion and git services commented on GEODE-7421: Commit f15bbc7839e1fd6eba8c28be1c3145dd86e895e6 in geode's branch refs/heads/feature/GEODE-7665 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-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=17052657#comment-17052657 ] ASF subversion and git services commented on GEODE-7808: Commit 5c2b959e98a6330ecaeddb4d26e11ea29f7a2d7f in geode's branch refs/heads/feature/GEODE-7665 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: 7h > 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-7832) Remove connection "send semaphores" from DirectChannel
[ https://issues.apache.org/jira/browse/GEODE-7832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17052653#comment-17052653 ] ASF subversion and git services commented on GEODE-7832: Commit 2a3e09f2da4793d08d1124b5d5e656285295937d in geode's branch refs/heads/feature/GEODE-7665 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 > 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-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=17052650#comment-17052650 ] ASF subversion and git services commented on GEODE-7808: Commit 4b06a7ae04e3eb3e32d8a6a96c7eb5e5d3269df0 in geode's branch refs/heads/feature/GEODE-7665 from Bruce Schuchardt [ https://gitbox.apache.org/repos/asf?p=geode.git;h=4b06a7a ] Revert "GEODE-7808: standardize on use of HostAndPort to form client-side connections (#4743)" (#4761) This reverts commit 0af626462642c6352840cd6e81a5265c74045c7f. That commit seems to have caused a severe performance drop in several Benchmark tests: org.apache.geode.benchmark.tests.PartitionedGetBenchmark average ops/second Baseline:981794.46 Test: 41239.82 Difference: -95.8% org.apache.geode.benchmark.tests.ReplicatedGetBenchmark average ops/second Baseline:972769.18 Test: 41299.96 Difference: -95.8% org.apache.geode.benchmark.tests.PartitionedNonIndexedQueryBenchmark average ops/second Baseline:90.05 Test:70.52 Difference: -21.7% > 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: 7h > 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-7828) Convert backing store for Redis Hashes and Sets to single regions
[
https://issues.apache.org/jira/browse/GEODE-7828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17052651#comment-17052651
]
ASF subversion and git services commented on GEODE-7828:
Commit 2f6bf013368df5a4b5efe68162a4953f9a88bbf2 in geode's branch
refs/heads/feature/GEODE-7665 from Jens Deppe
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=2f6bf01 ]
GEODE-7828: Convert backing store for Redis Hashes and Sets to single regions
(#4745)
* GEODE-7828: Convert backing store for Redis Hashes and Sets to single regions
This PR builds on the work originally submitted by Greg Green in
https://github.com/apache/geode/pull/404. Also acknowledgements to Galen
O'Sullivan for addressing locking issues in that PR.
This commit changes the storage model of Redis hashes and sets from one
region per each Redis key to a single hash region and single set region.
The Redis key is now also the region key and the data is stored in a Map
and Set respectively in the region. Currently, the backing values do not
implement Delta changes, however this will be a future optimization.
This also fixes the inability of Redis keys to contain other characters
commonly used, such as colons (':').
- Add `RedisLockService` which manages a lock per key within a single
JVM. Locks are held in a WeakHasMap to allow for automatic cleanup
(prior PR work, using a pure ConcurrentHashMap, ended up leaking
memory since there is no straight-forward way to clean up unused
keys/locks).
- Add new tests including concurrency tests for hashes and sets
Co-authored-by: Greg Green
Co-authored-by: Ray Ingles
Co-authored-by: Sarah Abbey
Co-authored-by: John Hutchison
Co-authored-by: Murtuza Boxwala
Co-authored-by: Prasath Durairaj
Co-authored-by: Jens Deppe
> Convert backing store for Redis Hashes and Sets to single regions
> -
>
> Key: GEODE-7828
> URL: https://issues.apache.org/jira/browse/GEODE-7828
> Project: Geode
> Issue Type: Improvement
> Components: redis
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
> Fix For: 1.13.0
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Currently the Redis adapter creates separate regions for each new hash or
> set. This can be a significant performance impact when many hashes are being
> created. In addition, hashes are conventionally often named with colons (':')
> in their name - for example {{user:1000}}. This does not work as region names
> cannot contain colons.
> The work here will create a single region for hashes and a single region for
> sets.
--
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=17052611#comment-17052611
]
Darrel Schneider commented on GEODE-7830:
-
I think what I was missing was that you are not calling rebalance because you
know you have some resources to rebalance but just in case you do. I think you
are right that this could be a common use case for rebalance: "if anything in
the cluster is out of balance fix it otherwise don't do anything". I agree that
this makes sense for a rebalance that did not target a specific region.
> 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] [Assigned] (GEODE-7826) met error when run rebalance by REST API on running 2 locators of 1 vm
[
https://issues.apache.org/jira/browse/GEODE-7826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darrel Schneider reassigned GEODE-7826:
---
Assignee: Darrel Schneider
> met error when run rebalance by REST API on running 2 locators of 1 vm
> --
>
> Key: GEODE-7826
> URL: https://issues.apache.org/jira/browse/GEODE-7826
> Project: Geode
> Issue Type: Bug
> Components: management, rest (admin)
>Reporter: Gang Yan
>Assignee: Darrel Schneider
>Priority: Major
>
> the reproduced steps:
> 1. gfsh start locator --port=0 --http-service-port=8081 --name=loc1
> 2. gfsh start locator --port=0 --name=loc2
> 3. gfsh start server --server-port=0 --name=s1
> 4. gfsh create region --name=/regionTest --type=PARTITION
> 5. java code to put 10 million data to regionTest
> 6. gfsh start server --server-port=0 --name=s2
> 7.run rebalance by [post] "
> http://127.0.0.1:7070/management/v1/operations/rebalances;
> 8. run [GET]"http://127.0.0.1:8081/management/v1/operations/rebalances;
> 9. met the following error
> {code:java}
> {
> "statusCode": "ERROR",
> "links": {
> "self":
> "http://127.0.0.1:7070/management/v1/operations/rebalances/3bb2f394-3d21-4076-8c24-3cf3ce7bbbea;,
> "list": "http://127.0.0.1:7070/management/v1/operations/rebalances;
> },
> "operationStart": "2020-02-26T22:06:44.601Z",
> "operationEnd": "2020-02-26T22:06:44.603Z",
> "operationId": "3bb2f394-3d21-4076-8c24-3cf3ce7bbbea",
> "operation": {
> "simulate": false
> },
> "throwable": {
> "stackTrace": [
> {
> "methodName": "getMemberRegionList",
> "fileName": "RebalanceOperationPerformer.java",
> "lineNumber": 208,
> "className":
> "org.apache.geode.management.internal.operation.RebalanceOperationPerformer",
> "nativeMethod": false
> },
> {
> "methodName": "executeRebalanceOnDS",
> "fileName": "RebalanceOperationPerformer.java",
> "lineNumber": 326,
> "className":
> "org.apache.geode.management.internal.operation.RebalanceOperationPerformer",
> "nativeMethod": false
> },
> {
> "methodName": "perform",
> "fileName": "RebalanceOperationPerformer.java",
> "lineNumber": 91,
> "className":
> "org.apache.geode.management.internal.operation.RebalanceOperationPerformer",
> "nativeMethod": false
> },
> {
> "methodName": "lambda$submit$0",
> "fileName": "OperationManager.java",
> "lineNumber": 67,
> "className":
> "org.apache.geode.management.internal.operation.OperationManager",
> "nativeMethod": false
> },
> {
> "methodName": "run",
> "fileName": "CompletableFuture.java",
> "lineNumber": 1590,
> "className":
> "java.util.concurrent.CompletableFuture$AsyncSupply",
> "nativeMethod": false
> },
> {
> "methodName": "run",
> "fileName": "Thread.java",
> "lineNumber": 748,
> "className": "java.lang.Thread",
> "nativeMethod": false
> }
> ]
> }
> }
> {code}
> expected things, 1 of the followings:
> 1. stop or forbid users to run rebalance on the non-jmxManager locator
> 2. return instructive info to let users find proper way to run rebalance
> 3. stop or forbid a REST API for Management to run , when there is no
> jmx-manager on the locator.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7826) met error when run rebalance by REST API on running 2 locators of 1 vm
[
https://issues.apache.org/jira/browse/GEODE-7826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17052571#comment-17052571
]
Darrel Schneider commented on GEODE-7826:
-
I think the fix for this is to have any locator that has the
management-rest-service for itself to be a jmx-manager.
I think it can do this by calling SystemManagerService.startManager(). It could
do this in InternalLocator.startClusterManagementService right before it calls
"addWebApplication".
> met error when run rebalance by REST API on running 2 locators of 1 vm
> --
>
> Key: GEODE-7826
> URL: https://issues.apache.org/jira/browse/GEODE-7826
> Project: Geode
> Issue Type: Bug
> Components: management, rest (admin)
>Reporter: Gang Yan
>Priority: Major
>
> the reproduced steps:
> 1. gfsh start locator --port=0 --http-service-port=8081 --name=loc1
> 2. gfsh start locator --port=0 --name=loc2
> 3. gfsh start server --server-port=0 --name=s1
> 4. gfsh create region --name=/regionTest --type=PARTITION
> 5. java code to put 10 million data to regionTest
> 6. gfsh start server --server-port=0 --name=s2
> 7.run rebalance by [post] "
> http://127.0.0.1:7070/management/v1/operations/rebalances;
> 8. run [GET]"http://127.0.0.1:8081/management/v1/operations/rebalances;
> 9. met the following error
> {code:java}
> {
> "statusCode": "ERROR",
> "links": {
> "self":
> "http://127.0.0.1:7070/management/v1/operations/rebalances/3bb2f394-3d21-4076-8c24-3cf3ce7bbbea;,
> "list": "http://127.0.0.1:7070/management/v1/operations/rebalances;
> },
> "operationStart": "2020-02-26T22:06:44.601Z",
> "operationEnd": "2020-02-26T22:06:44.603Z",
> "operationId": "3bb2f394-3d21-4076-8c24-3cf3ce7bbbea",
> "operation": {
> "simulate": false
> },
> "throwable": {
> "stackTrace": [
> {
> "methodName": "getMemberRegionList",
> "fileName": "RebalanceOperationPerformer.java",
> "lineNumber": 208,
> "className":
> "org.apache.geode.management.internal.operation.RebalanceOperationPerformer",
> "nativeMethod": false
> },
> {
> "methodName": "executeRebalanceOnDS",
> "fileName": "RebalanceOperationPerformer.java",
> "lineNumber": 326,
> "className":
> "org.apache.geode.management.internal.operation.RebalanceOperationPerformer",
> "nativeMethod": false
> },
> {
> "methodName": "perform",
> "fileName": "RebalanceOperationPerformer.java",
> "lineNumber": 91,
> "className":
> "org.apache.geode.management.internal.operation.RebalanceOperationPerformer",
> "nativeMethod": false
> },
> {
> "methodName": "lambda$submit$0",
> "fileName": "OperationManager.java",
> "lineNumber": 67,
> "className":
> "org.apache.geode.management.internal.operation.OperationManager",
> "nativeMethod": false
> },
> {
> "methodName": "run",
> "fileName": "CompletableFuture.java",
> "lineNumber": 1590,
> "className":
> "java.util.concurrent.CompletableFuture$AsyncSupply",
> "nativeMethod": false
> },
> {
> "methodName": "run",
> "fileName": "Thread.java",
> "lineNumber": 748,
> "className": "java.lang.Thread",
> "nativeMethod": false
> }
> ]
> }
> }
> {code}
> expected things, 1 of the followings:
> 1. stop or forbid users to run rebalance on the non-jmxManager locator
> 2. return instructive info to let users find proper way to run rebalance
> 3. stop or forbid a REST API for Management to run , when there is no
> jmx-manager on the locator.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (GEODE-7848) Remove NonCopyable and NonAssignable inheritance.
[ https://issues.apache.org/jira/browse/GEODE-7848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Bender closed GEODE-7848. --- > 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 >Priority: Major > Fix For: 1.13.0 > > Time Spent: 20m > Remaining Estimate: 0h > > 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] [Resolved] (GEODE-7848) Remove NonCopyable and NonAssignable inheritance.
[ https://issues.apache.org/jira/browse/GEODE-7848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Bender resolved GEODE-7848. - Fix Version/s: 1.13.0 Resolution: Fixed > 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 >Priority: Major > Fix For: 1.13.0 > > Time Spent: 20m > Remaining Estimate: 0h > > 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] [Commented] (GEODE-7848) Remove NonCopyable and NonAssignable inheritance.
[ https://issues.apache.org/jira/browse/GEODE-7848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17052505#comment-17052505 ] ASF subversion and git services commented on GEODE-7848: Commit 35fcb1a668e49c029563831922c40baf1cc8ef4a in geode-native's branch refs/heads/develop from Blake Bender [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=35fcb1a ] GEODE-7848: Removed inheritance of NonCopyable and NonAssignable (#579) - replaced with =delete member declarations > 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 >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > 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] [Commented] (GEODE-2484) Remove ACE from native client dependencies
[ https://issues.apache.org/jira/browse/GEODE-2484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17052472#comment-17052472 ] ASF subversion and git services commented on GEODE-2484: Commit 75942777fe05893bdd9fa17c58c13fde5d4c30af in geode-native's branch refs/heads/develop from Blake Bender [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=7594277 ] GEODE-2484: Removes more ACE mutex. (#578) - Cleanup other ACE headers. > Remove ACE from native client dependencies > -- > > Key: GEODE-2484 > URL: https://issues.apache.org/jira/browse/GEODE-2484 > Project: Geode > Issue Type: Task > Components: native client >Reporter: David Kimura >Priority: Major > Labels: pull-request-available > Fix For: 1.9.0 > > Time Spent: 10h 50m > Remaining Estimate: 0h > > Remove ACE from native client dependencies. > Replace ACE usage with C++11 and/or Boost 1.63+ -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7841) Add benchmarking scripts for Geode-Redis module
[ https://issues.apache.org/jira/browse/GEODE-7841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17052448#comment-17052448 ] ASF subversion and git services commented on GEODE-7841: Commit b57456e2cd9f179cf018adaf676a9b78bdc98270 in geode's branch refs/heads/develop from Jens Deppe [ https://gitbox.apache.org/repos/asf?p=geode.git;h=b57456e ] GEODE-7841 Add benchmarking scripts for Geode-Redis module (#4763) > Add benchmarking scripts for Geode-Redis module > --- > > Key: GEODE-7841 > URL: https://issues.apache.org/jira/browse/GEODE-7841 > Project: Geode > Issue Type: New Feature > Components: benchmarks, redis >Reporter: Raymond Ingles >Assignee: Jens Deppe >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > Add the following scripts to the Geode-Redis module, in the "performanceTest" > directory: > * aggregator.sh runs the actual tests > * benchmark.sh handles validating the redis server (e.g. starting and > stopping Geode Redis if needed), then runs aggregator.sh > * shacompare.sh takes two git SHAs as arguments and runs benchmark.sh on > each of them, generating separate output files for each. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (GEODE-7852) Add client side configuration option to support a SNI proxy
[ https://issues.apache.org/jira/browse/GEODE-7852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17052391#comment-17052391 ] Bill Burcham edited comment on GEODE-7852 at 3/5/20, 6:10 PM: -- this story will eliminate the system property introduced in GEODE-7837 right? was (Author: bburcham): this story will eliminate the system property right? > Add client side configuration option to support a SNI proxy > --- > > Key: GEODE-7852 > URL: https://issues.apache.org/jira/browse/GEODE-7852 > Project: Geode > Issue Type: Improvement > Components: client/server, membership >Reporter: Dan Smith >Assignee: Dan Smith >Priority: Major > > Add an option to the client side configuration to support a the use of a [SNI > proxy|https://www.bamsoftware.com/computers/sniproxy/]. > See also GEODE-7837, which adds a system property to support a SNI proxy. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7852) Add client side configuration option to support a SNI proxy
[ https://issues.apache.org/jira/browse/GEODE-7852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17052391#comment-17052391 ] Bill Burcham commented on GEODE-7852: - this story will eliminate the system property right? > Add client side configuration option to support a SNI proxy > --- > > Key: GEODE-7852 > URL: https://issues.apache.org/jira/browse/GEODE-7852 > Project: Geode > Issue Type: Improvement > Components: client/server, membership >Reporter: Dan Smith >Assignee: Dan Smith >Priority: Major > > Add an option to the client side configuration to support a the use of a [SNI > proxy|https://www.bamsoftware.com/computers/sniproxy/]. > See also GEODE-7837, which adds a system property to support a SNI proxy. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7852) Add client side configuration option to support a SNI proxy
[ https://issues.apache.org/jira/browse/GEODE-7852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith updated GEODE-7852: - Component/s: membership > Add client side configuration option to support a SNI proxy > --- > > Key: GEODE-7852 > URL: https://issues.apache.org/jira/browse/GEODE-7852 > Project: Geode > Issue Type: Improvement > Components: client/server, membership >Reporter: Dan Smith >Assignee: Dan Smith >Priority: Major > > Add an option to the client side configuration to support a the use of a [SNI > proxy|https://www.bamsoftware.com/computers/sniproxy/]. > See also GEODE-7837, which adds a system property to support a SNI proxy. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-7852) Add client side configuration option to support a SNI proxy
[ https://issues.apache.org/jira/browse/GEODE-7852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith reassigned GEODE-7852: Assignee: Dan Smith > Add client side configuration option to support a SNI proxy > --- > > Key: GEODE-7852 > URL: https://issues.apache.org/jira/browse/GEODE-7852 > Project: Geode > Issue Type: Improvement > Components: client/server >Reporter: Dan Smith >Assignee: Dan Smith >Priority: Major > > Add an option to the client side configuration to support a the use of a [SNI > proxy|https://www.bamsoftware.com/computers/sniproxy/]. > See also GEODE-7837, which adds a system property to support a SNI proxy. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-7852) Add client side configuration option to support a SNI proxy
Dan Smith created GEODE-7852: Summary: Add client side configuration option to support a SNI proxy Key: GEODE-7852 URL: https://issues.apache.org/jira/browse/GEODE-7852 Project: Geode Issue Type: Improvement Components: client/server Reporter: Dan Smith Add an option to the client side configuration to support a the use of a [SNI proxy|https://www.bamsoftware.com/computers/sniproxy/]. See also GEODE-7837, which adds a system property to support a SNI proxy. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7840) Redis pub/sub does not handle binary messages correctly
[ https://issues.apache.org/jira/browse/GEODE-7840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17052368#comment-17052368 ] ASF subversion and git services commented on GEODE-7840: Commit 838e0704ed03b0008b4b62f10269b7eed1bd7e18 in geode's branch refs/heads/develop from Jens Deppe [ https://gitbox.apache.org/repos/asf?p=geode.git;h=838e070 ] GEODE-7840: Redis pub/sub does not handle binary messages correctly (#4762) > Redis pub/sub does not handle binary messages correctly > --- > > Key: GEODE-7840 > URL: https://issues.apache.org/jira/browse/GEODE-7840 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > The new pub/sub functionality currently only considers published messages to > be actual strings and does not account for them being binary data. This > results in messages being corrupted since they end up being UTF-8 encoded. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-7513) PersistentColocatedPartitionedRegionDistributedTest.testFullTreeOfColocatedChildPRsWithMissingRegions fails with org.mockito.exceptions.verification.NoInteractionsWanted
[
https://issues.apache.org/jira/browse/GEODE-7513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund resolved GEODE-7513.
--
Fix Version/s: 1.13.0
Resolution: Fixed
> PersistentColocatedPartitionedRegionDistributedTest.testFullTreeOfColocatedChildPRsWithMissingRegions
> fails with org.mockito.exceptions.verification.NoInteractionsWanted
> -
>
> Key: GEODE-7513
> URL: https://issues.apache.org/jira/browse/GEODE-7513
> Project: Geode
> Issue Type: Bug
> Components: core, tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Labels: flaky
> Fix For: 1.13.0
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> Failed in CI
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/1330:
> {noformat}
> org.apache.geode.internal.cache.partitioned.PersistentColocatedPartitionedRegionDistributedTest
> > testFullTreeOfColocatedChildPRsWithMissingRegions FAILED
> java.lang.AssertionError: An exception occurred during asynchronous
> invocation.
> at
> org.apache.geode.test.dunit.AsyncInvocation.checkException(AsyncInvocation.java:297)
> at
> org.apache.geode.test.dunit.AsyncInvocation.await(AsyncInvocation.java:448)
> at
> org.apache.geode.test.dunit.AsyncInvocation.await(AsyncInvocation.java:178)
> at
> org.apache.geode.internal.cache.partitioned.PersistentColocatedPartitionedRegionDistributedTest.testFullTreeOfColocatedChildPRsWithMissingRegions(PersistentColocatedPartitionedRegionDistributedTest.java:767)
> Caused by:
> org.mockito.exceptions.verification.NoInteractionsWanted:
> No interactions wanted here:
> -> at
> org.apache.geode.internal.cache.partitioned.PersistentColocatedPartitionedRegionDistributedTest.validateColocationLogger_withChildRegionTree(PersistentColocatedPartitionedRegionDistributedTest.java:1987)
> But found this interaction on mock 'consumer':
> -> at
> org.apache.geode.internal.cache.partitioned.colocation.SingleThreadColocationLogger.logMissingRegions(SingleThreadColocationLogger.java:216)
> ***
> For your reference, here is the list of all invocations ([?] - means
> unverified).
> 1. -> at
> org.apache.geode.internal.cache.partitioned.colocation.SingleThreadColocationLogger.logMissingRegions(SingleThreadColocationLogger.java:216)
> 2. [?]-> at
> org.apache.geode.internal.cache.partitioned.colocation.SingleThreadColocationLogger.logMissingRegions(SingleThreadColocationLogger.java:216)
> at
> org.apache.geode.internal.cache.partitioned.PersistentColocatedPartitionedRegionDistributedTest.validateColocationLogger_withChildRegionTree(PersistentColocatedPartitionedRegionDistributedTest.java:1987)
> at
> org.apache.geode.internal.cache.partitioned.PersistentColocatedPartitionedRegionDistributedTest.lambda$testFullTreeOfColocatedChildPRsWithMissingRegions$43440a96$1(PersistentColocatedPartitionedRegionDistributedTest.java:764)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-7810) Cannot form connection to alert listener should be logged at WARNING level
[
https://issues.apache.org/jira/browse/GEODE-7810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund resolved GEODE-7810.
--
Fix Version/s: 1.13.0
Resolution: Fixed
> Cannot form connection to alert listener should be logged at WARNING level
> --
>
> Key: GEODE-7810
> URL: https://issues.apache.org/jira/browse/GEODE-7810
> Project: Geode
> Issue Type: Bug
> Components: logging, management
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Fix For: 1.13.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> The Cannot form connection to alert listener log message is currently being
> logged at FATAL level. This should be logged as a WARNING (or ERROR) instead.
> {noformat}
> java.io.IOException: Cannot form connection to alert listener
> 172.17.0.7(locator2:1:locator):41002
> at
> org.apache.geode.internal.tcp.Connection.createSender(Connection.java:998)
> at
> org.apache.geode.internal.tcp.ConnectionTable.handleNewPendingConnection(ConnectionTable.java:288)
> at
> org.apache.geode.internal.tcp.ConnectionTable.getSharedConnection(ConnectionTable.java:392)
> at
> org.apache.geode.internal.tcp.ConnectionTable.get(ConnectionTable.java:567)
> at
> org.apache.geode.internal.tcp.TCPConduit.getConnection(TCPConduit.java:782)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.getConnections(DirectChannel.java:545)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:334)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:248)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:604)
> at
> org.apache.geode.distributed.internal.DistributionImpl.directChannelSend(DistributionImpl.java:348)
> at
> org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:293)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2061)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:1988)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendMessage(ClusterDistributionManager.java:2025)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.putOutgoing(ClusterDistributionManager.java:1085)
> at
> org.apache.geode.alerting.internal.ClusterAlertMessaging.lambda$null$0(ClusterAlertMessaging.java:92)
> at
> org.apache.geode.alerting.internal.spi.AlertingAction.execute(AlertingAction.java:34)
> at
> org.apache.geode.alerting.internal.ClusterAlertMessaging.lambda$sendAlert$1(ClusterAlertMessaging.java:70)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-6659) CI failure: DistributedSystemMXBeanWithAlertsDistributedTest > managerReceivesAlertsFromAllMembersAtAlertLevelAndAbove cannot send "cache closed" message
[
https://issues.apache.org/jira/browse/GEODE-6659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund resolved GEODE-6659.
--
Fix Version/s: 1.13.0
Resolution: Fixed
Fixed by the changes for GEODE-7810.
> CI failure: DistributedSystemMXBeanWithAlertsDistributedTest >
> managerReceivesAlertsFromAllMembersAtAlertLevelAndAbove cannot send "cache
> closed" message
> -
>
> Key: GEODE-6659
> URL: https://issues.apache.org/jira/browse/GEODE-6659
> Project: Geode
> Issue Type: Bug
> Components: core, logging, membership
>Reporter: Dale Emery
>Assignee: Kirk Lund
>Priority: Major
> Fix For: 1.13.0
>
>
> When the cache is closed during test teardown, it can't get a connection to
> send the "cache closing" message. It then tries to send an alert about that
> failure, and it can't get a connection to send that either. So it throws
> IOException and bails out.
> CI failure:
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/624]
> Test results:
> [http://files.apachegeode-ci.info/builds/apache-develop-main/1.10.0-SNAPSHOT.0183/test-results/distributedTest/1555361324/]
> Stack trace:
> {noformat}
> 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 2457
> [fatal 2019/04/15 19:48:11.076 UTC tid=34]
> Failed to send message 172.17.0.3(managerVM:149):41001" level WARNING> to member
> <172.17.0.3(managerVM:149):41001> view,
> View[172.17.0.3(58:locator):41000|31] members:
> [172.17.0.3(58:locator):41000,
> 172.17.0.3(managerVM:149):41001{lead},
> 172.17.0.3(memberVM-1:153):41002, 172.17.0.3(memberVM-2:158):41003,
> 172.17.0.3(memberVM-3:162):41004]
> java.io.IOException: Cannot form connection to alert listener
> 172.17.0.3(managerVM:149):41001
> at
> org.apache.geode.internal.tcp.Connection.createSender(Connection.java:952)
> at
> org.apache.geode.internal.tcp.ConnectionTable.handleNewPendingConnection(ConnectionTable.java:293)
> at
> org.apache.geode.internal.tcp.ConnectionTable.getSharedConnection(ConnectionTable.java:404)
> at
> org.apache.geode.internal.tcp.ConnectionTable.get(ConnectionTable.java:589)
> at
> org.apache.geode.internal.tcp.TCPConduit.getConnection(TCPConduit.java:824)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.getConnections(DirectChannel.java:536)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:326)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:241)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:595)
> at
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.directChannelSend(GMSMembershipManager.java:1710)
> at
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.send(GMSMembershipManager.java:1891)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2852)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:2779)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendMessage(ClusterDistributionManager.java:2816)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.putOutgoing(ClusterDistributionManager.java:1526)
> at
> org.apache.geode.internal.alerting.AlertMessaging.sendAlert(AlertMessaging.java:75)
> at
> org.apache.geode.internal.logging.log4j.AlertAppender.sendAlertMessage(AlertAppender.java:187)
> at
> org.apache.geode.internal.logging.log4j.AlertAppender.doAppend(AlertAppender.java:162)
> at
> org.apache.geode.internal.logging.log4j.AlertAppender.lambda$append$0(AlertAppender.java:158)
> at
> org.apache.geode.internal.alerting.AlertingAction.execute(AlertingAction.java:29)
> at
> org.apache.geode.internal.logging.log4j.AlertAppender.append(AlertAppender.java:158)
> at
> org.apache.logging.log4j.core.config.AppenderControl.tryCallAppender(AppenderControl.java:156)
> at
> org.apache.logging.log4j.core.config.AppenderControl.callAppender0(AppenderControl.java:129)
> at
> org.apache.logging.log4j.core.config.AppenderControl.callAppenderPreventRecursion(AppenderControl.java:120)
> at
>
[jira] [Resolved] (GEODE-7819) Add debugging support to SerializableTemporaryFolder
[ https://issues.apache.org/jira/browse/GEODE-7819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund resolved GEODE-7819. -- Fix Version/s: 1.13.0 Resolution: Fixed > Add debugging support to SerializableTemporaryFolder > > > Key: GEODE-7819 > URL: https://issues.apache.org/jira/browse/GEODE-7819 > Project: Geode > Issue Type: Wish > Components: tests >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Fix For: 1.13.0 > > Time Spent: 20m > Remaining Estimate: 0h > > When we are debugging a distributed test that uses > SerializableTemporaryFolder for Server and Locator files, we need a way to > save off the files. This is especially important for debugging remote > failures in the cloud. -- 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=17052339#comment-17052339 ] ASF subversion and git services commented on GEODE-7808: Commit 61949a99feeb6553cfd915c6470da2007589324b in geode's branch refs/heads/feature/GEODE-7808_testing_wip from Bruce Schuchardt [ https://gitbox.apache.org/repos/asf?p=geode.git;h=61949a9 ] GEODE-7808: standardize on use of HostAndPort for connection formation Adding two tests that limit the use of InetAddress and of InetSocketAddress.getAddress(). Ideally we could whittle down the list of exceptions currently being "sanctioned" by the InetAddress test. I tried using the PMD tool that's already built into our gradle builds to perform these restrictions but it fails with parsing errors. Instead I turned to the "decode" package that's used by AnalyzeSerializablesTestBase and refactored that into a Rule that can be used by any test to load its module's class files in partially decompiled form. I added a couple of query methods to CompiledClass to search for uses of InetAddress and InetSocketAddress.getAddress(). The InetAddress test turned up 74 violations. I removed some of these by getting rid of unnecessary code or moving it to LocalHostUtil and categorized the other violations and moved them into a "sanctioned" list that we should work on making as small as possible. > 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-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=17052311#comment-17052311
]
Aaron Lindsey commented on GEODE-7830:
--
The "operator" in my case is actually a Kubernetes controller. It calls
rebalance each time Kubernetes tries to stop a Geode server to ensure data is
not lost. In this case it is very common to call rebalance when there are no
regions, e.g. during a scaling operation before the user has created any
regions. Right now we have to parse the status message to determine if the
rebalance failed due to the no-op error, and then ignore it.
Do you know if having no regions is the only reason the rebalance API will
return the no-op error? If we were sure of that, then we could call list
regions to make sure regions exist before calling rebalance.
FWIW, I think it would be best to assume that consumers of this REST API will
be programs, not humans, and therefore we should design it in such a way that
it would be easy to consume programatically. It's much more reliable to
programmatically check the size of an array rather than parse a status message
to determine if the rebalance succeeded.
> 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] [Updated] (GEODE-7838) Info about num of servers during rebalance command
[ https://issues.apache.org/jira/browse/GEODE-7838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Kevo updated GEODE-7838: -- Labels: pull-request-available (was: ) > Info about num of servers during rebalance command > -- > > Key: GEODE-7838 > URL: https://issues.apache.org/jira/browse/GEODE-7838 > Project: Geode > Issue Type: Improvement > Components: gfsh >Reporter: Mario Kevo >Assignee: Mario Kevo >Priority: Major > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > In case during rebalance some members joined or departed rebalance will > automatically restarted. > But from the user side it can not see on how many members rebalance was > executed. > We have a situation when have 3 servers and during rebalance one is departed > and rebalance is executed on other 2 servers. But after rebalance is finished > server is back and user have a wrong perception on how many servers rebalance > is executed. > It will be good to have another row in result table to print this message. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-6536) client pr single hop will do multiple hops if things get busy
[
https://issues.apache.org/jira/browse/GEODE-6536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols updated GEODE-6536:
Fix Version/s: (was: 1.13.0)
> client pr single hop will do multiple hops if things get busy
> -
>
> Key: GEODE-6536
> URL: https://issues.apache.org/jira/browse/GEODE-6536
> Project: Geode
> Issue Type: Improvement
> Components: client/server
>Reporter: Darrel Schneider
>Assignee: Mario Ivanac
>Priority: Major
> Labels: needs-review, performance, pull-request-available
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> I was wondering why ConnectionManagerImpl.borrowConnection that targets a
> particular server will not wait for a connection to be available. This is the
> borrow used by pr single hop. It seems like if all the cnxs to that server
> are busy and we are at max that it should wait. But instead it does a single
> scan of the pool and if it does not find an idle connection it either throws
> AllConnectionsInUse or it creates one. The caller sets the onlyUseExistingCnx
> parameter based on if the pool is at max cnxs or not (seems like this should
> have been done in borrowConnection instead of the caller). If it throws
> AllConnectionsInUse the caller catches it and ignores it and then falls into
> doing a non-targeted borrow that will wait for a connection but to ANY
> server. So our single hop optimization goes away on a busy client. Since it
> can’t immediately get a connection to server A, it says just give me a
> connection to any server sends the op to that other server and that server
> ends up having to forward it to server A. You would only see this problem if
> you set a max on your client connection pool. The default of -1 just says to
> always create another connection. The only workaround I know of is to not
> limit how many connections your client can create but that could cause other
> problem (i.e. too many file descriptors).
> The questionable code is in the following classes:
> org.apache.geode.cache.client.internal.GetOp
> org.apache.geode.cache.client.internal.PutOp
> org.apache.geode.cache.client.internal.DestroyOp
> The all have something like this:
>
> {code:java}
> boolean onlyUseExistingCnx = ((poolImpl.getMaxConnections() != -1
> && poolImpl.getConnectionCount() >= poolImpl.getMaxConnections()) ? true :
> false);
> op.setAllowDuplicateMetadataRefresh(!onlyUseExistingCnx);
> return pool.executeOn(new ServerLocation(server.getHostName(),
> server.getPort()), op,
> true, onlyUseExistingCnx);
> {code}
> executeOn eventually calls ConnectionManagerImpl.borrowConnection
> It is unclear to me why they need allow duplicate metadata refresh if they
> permit borrowConnection to create a new connection to the specified server.
> They all catch and ignore
> AllConnectionsInUseException falling through and doing non-targetted
> pool.execute.
> The concern might have been that the pool would be full of connections to
> other servers preventing us from connecting to the server we need to
> communicate with. If we have existing connections to the server we could wait
> for one of those. If we don't and we are at max then we should consider
> closing a connection to some other server and create a connection to the
> server we know we need for this operation. As the server count goes up and
> the max connection count on the pool goes down I'm sure we are probably
> better off not even trying to do single hop since we might not even be able
> to have a connection to each server in the pool. But if we have a reasonable
> max connection count then it seems like we could make more of an effort to
> make sure a per server connection count is balanced and then wait for one of
> those connection to be available.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
