jdeppe-pivotal commented on a change in pull request #6831:
URL: https://github.com/apache/geode/pull/6831#discussion_r702117757
##########
File path:
geode-apis-compatible-with-redis/src/main/java/org/apache/geode/redis/internal/data/RedisSortedSet.java
##########
@@ -377,6 +382,25 @@ long zrevrank(byte[] member) {
return scoreSet.size() - scoreSet.indexOf(orderedSetEntry) - 1;
}
+ ImmutablePair<Integer, List<byte[]>> zscan(Pattern matchPattern, int count,
int cursor) {
+ // No need to allocate more space than it's possible to use given the size
of the sorted set. We
+ // need to add 1 to zcard() to ensure that if count > members.size(), we
return a cursor of 0
+ long maximumCapacity = 2L * Math.min(count, zcard() + 1);
+ if (maximumCapacity > Integer.MAX_VALUE) {
+ LogService.getLogger().info(
+ "The size of the data to be returned by zscan, {}, exceeds the
maximum capacity of an array. A value for the ZSCAN COUNT argument less than {}
should be used",
+ maximumCapacity, Integer.MAX_VALUE / 2);
+ throw new IllegalArgumentException("Requested array size exceeds VM
limit");
+ }
+ List<byte[]> resultList = new ArrayList<>((int) maximumCapacity);
+ do {
+ cursor = members.scan(cursor, 1,
Review comment:
That's pretty annoying :) I'd still argue for restoring the prior
behavior (or some variant) since it should be more performant overall in that
it will reduce the potential number of client calls. If we only process `count`
entries for every `scan` call, the client is going to make ~`set_size / count`
requests until they are done. The downside of the original implementation is
that the key is locked for the duration of the call as more entries are
iterated. Since the semantics are so loose, it would be awesome if the scan
could be interrupted by a write operation, but that's just crazy talk...
Even Redis requires a lot of calls when the matches are sparse. With a set
of 10003 entries where 3 entries will match the `zscan` call (and count=3),
Redis still takes 2769 calls before the whole set is processed, so I guess
leaving this change is OK for now.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]