You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@geode.apache.org by GitBox <gi...@apache.org> on 2021/01/29 23:01:01 UTC
[GitHub] [geode] jdeppe-pivotal opened a new pull request #5980: GEODE-8897: Improve Redis INCRBYFLOAT output accuracy for very large values
jdeppe-pivotal opened a new pull request #5980:
URL: https://github.com/apache/geode/pull/5980
- Switch to using BigDecimal instead of double for increment value.
- Also mark INCRBYFLOAT as supported.
- Add concurrency tests.
Thank you for submitting a contribution to Apache Geode.
In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:
### For all changes:
- [ ] Is there a JIRA ticket associated with this PR? Is it referenced in the commit message?
- [ ] Has your PR been rebased against the latest commit within the target branch (typically `develop`)?
- [ ] Is your initial contribution a single, squashed commit?
- [ ] Does `gradlew build` run cleanly?
- [ ] Have you written or updated unit tests to verify your changes?
- [ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under [ASF 2.0](http://www.apache.org/legal/resolved.html#category-a)?
### Note:
Please ensure that once the PR is submitted, check Concourse for build issues and
submit an update to your PR as soon as possible. If you need help, please send an
email to dev@geode.apache.org.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [geode] sabbey37 commented on a change in pull request #5980: GEODE-8897: Improve Redis INCRBYFLOAT output accuracy for very large values
Posted by GitBox <gi...@apache.org>.
sabbey37 commented on a change in pull request #5980:
URL: https://github.com/apache/geode/pull/5980#discussion_r567904593
##########
File path: geode-redis/src/main/java/org/apache/geode/redis/internal/data/RedisString.java
##########
@@ -88,18 +89,16 @@ public long incrby(Region<ByteArrayWrapper, RedisData> region, ByteArrayWrapper
return longValue;
}
- public double incrbyfloat(Region<ByteArrayWrapper, RedisData> region, ByteArrayWrapper key,
- double increment)
+ public BigDecimal incrbyfloat(Region<ByteArrayWrapper, RedisData> region, ByteArrayWrapper key,
+ BigDecimal increment)
throws NumberFormatException, ArithmeticException {
- double doubleValue = parseValueAsDouble();
- doubleValue += increment;
- if (Double.isNaN(doubleValue) || Double.isInfinite(doubleValue)) {
- throw new ArithmeticException(RedisConstants.ERROR_NAN_OR_INFINITY);
- }
Review comment:
Same question as above, don't know if we'd still want to cap the BigDecimal value (maybe make it the same as Redis's and send that `ERROR_NAN_OR_INFINITY` if the value is exceeded) so we don't run out of memory?
##########
File path: geode-redis/src/integrationTest/java/org/apache/geode/redis/internal/executor/string/AbstractIncrByFloatIntegrationTest.java
##########
@@ -172,4 +163,32 @@ public void testIncrByFloat_withReallyBigNumbers() {
assertThat(result.toPlainString()).isEqualTo(biggy.add(BigDecimal.ONE).toPlainString());
}
+
+ @Test
+ public void testConcurrentIncrByFloat_performsAllIncrByFloats() {
+ String key = "key";
+ Random random = new Random();
+ Jedis jedis2 = new Jedis("localhost", getPort(), JEDIS_TIMEOUT);
+
+ AtomicReference<BigDecimal> expectedValue = new AtomicReference<>();
+ expectedValue.set(new BigDecimal(0));
+
+ jedis.set(key, "0");
+
+ new ConcurrentLoopingThreads(1000,
+ (i) -> {
+ BigDecimal increment = BigDecimal.valueOf(random.nextInt(37));
Review comment:
This is a great number.
##########
File path: geode-redis/src/integrationTest/java/org/apache/geode/redis/internal/executor/string/AbstractIncrByFloatIntegrationTest.java
##########
@@ -150,17 +152,6 @@ public void testIncrByFloat_withInfinityAndVariants() {
}
@Test
- public void testIncrByFloat_whenIncrWillOverflowProducesCorrectError() {
- BigDecimal longDouble = new BigDecimal("1.1E+4932");
- jedis.set("number", longDouble.toPlainString());
-
- assertThatThrownBy(
- () -> jedis.sendCommand(Protocol.Command.INCRBYFLOAT, "number", longDouble.toString()))
- .hasMessage("ERR increment would produce NaN or Infinity");
- }
Review comment:
I realize we won't run into the overflow issue since we're using BigDecimal now, but would we still want to cap the value so we don't run out of memory?
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [geode] jdeppe-pivotal merged pull request #5980: GEODE-8897: Improve Redis INCRBYFLOAT output accuracy for very large values
Posted by GitBox <gi...@apache.org>.
jdeppe-pivotal merged pull request #5980:
URL: https://github.com/apache/geode/pull/5980
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org