[ 
https://issues.apache.org/jira/browse/BEAM-7948?focusedWorklogId=336857&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-336857
 ]

ASF GitHub Bot logged work on BEAM-7948:
----------------------------------------

                Author: ASF GitHub Bot
            Created on: 31/Oct/19 16:21
            Start Date: 31/Oct/19 16:21
    Worklog Time Spent: 10m 
      Work Description: lukecwik commented on pull request #9949: [BEAM-7948] 
Add time-based cache threshold support in the Java data s…
URL: https://github.com/apache/beam/pull/9949#discussion_r341234459
 
 

 ##########
 File path: 
sdks/java/fn-execution/src/test/java/org/apache/beam/sdk/fn/data/BeamFnDataBufferingOutboundObserverTest.java
 ##########
 @@ -146,6 +159,85 @@ public void testConfiguredBufferLimit() throws Exception {
         Iterables.get(values, 1));
   }
 
+  @Test
+  public void testConfiguredTimeLimit() throws Exception {
+    Collection<BeamFnApi.Elements> values = new ArrayList<>();
+    AtomicBoolean onCompletedWasCalled = new AtomicBoolean();
+    PipelineOptions options = PipelineOptionsFactory.create();
+    options
+        .as(ExperimentalOptions.class)
+        .setExperiments(Arrays.asList("beam_fn_api_data_buffer_time_limit=1"));
+    CloseableFnDataReceiver<WindowedValue<byte[]>> consumer =
+        BeamFnDataBufferingOutboundObserver.forLocation(
+            options,
+            OUTPUT_LOCATION,
+            CODER,
+            TestStreams.withOnNext(addToValuesConsumer(values))
+                .withOnCompleted(setBooleanToTrue(onCompletedWasCalled))
+                .build());
+
+    // Test that it emits when time passed the time limit
+    consumer.accept(valueInGlobalWindow(new byte[1]));
+    Thread.sleep(10); // allow the flush thread to flush the buffer
+    assertEquals(messageWithData(new byte[1]), Iterables.get(values, 0));
+  }
+
+  @Test
+  public void testConfiguredTimeLimitExceptionPropagation() throws Exception {
+    AtomicBoolean onCompletedWasCalled = new AtomicBoolean();
+    PipelineOptions options = PipelineOptionsFactory.create();
+    options
+        .as(ExperimentalOptions.class)
+        .setExperiments(Arrays.asList("beam_fn_api_data_buffer_time_limit=1"));
+    CloseableFnDataReceiver<WindowedValue<byte[]>> consumer =
+        BeamFnDataBufferingOutboundObserver.forLocation(
+            options,
+            OUTPUT_LOCATION,
+            CODER,
+            TestStreams.withOnNext(
+                    (Consumer<Elements>)
+                        t -> {
+                          throw new RuntimeException("");
+                        })
+                .withOnCompleted(setBooleanToTrue(onCompletedWasCalled))
+                .build());
+
+    // Test that it emits when time passed the time limit
+    consumer.accept(valueInGlobalWindow(new byte[1]));
+    Thread.sleep(100); // allow the flush thread to flush the buffer
 
 Review comment:
   ditto here to use a semaphore/lock/countdownlatch instead of thread.sleep
 
----------------------------------------------------------------
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:
[email protected]


Issue Time Tracking
-------------------

    Worklog Id:     (was: 336857)
    Time Spent: 20m  (was: 10m)

> Add time-based cache threshold support in the Java data service
> ---------------------------------------------------------------
>
>                 Key: BEAM-7948
>                 URL: https://issues.apache.org/jira/browse/BEAM-7948
>             Project: Beam
>          Issue Type: Sub-task
>          Components: java-fn-execution
>            Reporter: sunjincheng
>            Assignee: sunjincheng
>            Priority: Major
>          Time Spent: 20m
>  Remaining Estimate: 0h
>
> Currently only size-based cache threshold is supported in data service. It 
> should also support the time-based cache threshold. This is very important, 
> especially for streaming jobs which are sensitive to the delay.



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

Reply via email to