[jira] [Commented] (GEODE-8897) Improve Redis INCRBYFLOAT output accuracy for very large values

["ASF GitHub Bot (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/GEODE-8897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17276399#comment-17276399 ] 

ASF GitHub Bot commented on GEODE-8897:
---------------------------------------

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


> Improve Redis INCRBYFLOAT output accuracy for very large values
> ---------------------------------------------------------------
>
>                 Key: GEODE-8897
>                 URL: https://issues.apache.org/jira/browse/GEODE-8897
>             Project: Geode
>          Issue Type: Test
>          Components: redis
>            Reporter: Jens Deppe
>            Assignee: Jens Deppe
>            Priority: Major
>              Labels: pull-request-available
>
> Currently native redis appears to be able to apply INCRBYFLOAT on values that are below the max of unsigned long long (18446744073709551615). However, since we're treating numbers as \{{double}}s we can lose precision for very large values. For example:
>  
>  {{set val 18446744073709551614
> incrbyfloat val 1}}
> incorrectly returns {{18446744073709552000}}
> Native redis produces a correct result.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)