[GitHub] [geode] sabbey37 commented on a change in pull request #5980: GEODE-8897: Improve Redis INCRBYFLOAT output accuracy for very large values

[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