tolbertam commented on code in PR #1957:
URL:
https://github.com/apache/cassandra-java-driver/pull/1957#discussion_r1752989503
##########
core/src/test/java/com/datastax/oss/driver/internal/core/session/throttling/ConcurrencyLimitingRequestThrottlerTest.java:
##########
@@ -239,4 +243,83 @@ public void should_reject_enqueued_when_closing() {
assertThatStage(request.started)
.isFailed(error ->
assertThat(error).isInstanceOf(RequestThrottlingException.class));
}
+
+ @Test
+ public void should_run_throttle_callbacks_concurrently()
+ throws ExecutionException, InterruptedException, TimeoutException {
+ // Given
+
+ // a task is enqueued, which when in onThrottleReady, will stall for 100ms
+ // register() should automatically start onThrottleReady on same thread
+
+ // start a parallel thread
+ Runnable r =
+ () -> {
+ MockThrottled first = new MockThrottled(100);
+ throttler.register(first);
+ first.started.toCompletableFuture().thenRun(() ->
throttler.signalSuccess(first));
+ };
+ Thread t = new Thread(r);
+ t.start();
+
+ // wait for the registration threads to be launched
+ Uninterruptibles.sleepUninterruptibly(5, TimeUnit.MILLISECONDS);
Review Comment:
Took me a moment to wrap my head around this, but it does seem that sleeping
will allow deference to the scheduler to run those other threads?
It seems to deterministically work for me, but I wonder if it entirely is?
Another thing I tried was adding a CountDownLatch(5) and then updated
MockThrottled to optionally take a latch and calling latch.countDown() in
MockThrottled.doSleep() (before sleeping then using assertTrue(latch.await(1,
TimeUnit.SECONDS));. That seems like it would be more reliable to me, but I
can't seem to reproduce a failure with the way it is.
I do worry about possible CI sensitivity around timing, but I think we
should accept this as is and if it causes problems we could then reevaluate.
--
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
