Today `ThrottledIterator` may block in `run()` while waiting for another
thread to release the mutex on `iterator`, but this wait is unnecessary:
if some thread is already executing `run()` then all other threads
handling item completions can just release their permits and move on.

Today `ThrottledIterator` may block in `run()` while waiting for another
thread to release the mutex on `iterator`, but this wait is unnecessary:
if some thread is already executing `run()` then all other threads
handling item completions can just release their permits and move on.

Silly test mistake: the throttle was supposed to limit the number of
fragments in the queue, but was closing the throttling ref after
submission rather than transmission so that the queue could grow without
bound sometimes.

It's been like this since the test was introduced in elastic#111933, but it
only started failing recently. I suspect until the performance
improvement in elastic#139988 landed it couldn't actually submit enough tasks
at once to cause a failure.

Closes elastic#143644

Silly test mistake: the throttle was supposed to limit the number of
fragments in the queue, but was closing the throttling ref after
submission rather than transmission so that the queue could grow without
bound sometimes.

It's been like this since the test was introduced in #111933, but it
only started failing recently. I suspect until the performance
improvement in #139988 landed it couldn't actually submit enough tasks
at once to cause a failure.

Closes #143644

Silly test mistake: the throttle was supposed to limit the number of
fragments in the queue, but was closing the throttling ref after
submission rather than transmission so that the queue could grow without
bound sometimes.

It's been like this since the test was introduced in elastic#111933, but it
only started failing recently. I suspect until the performance
improvement in elastic#139988 landed it couldn't actually submit enough tasks
at once to cause a failure.

Closes elastic#143644

Silly test mistake: the throttle was supposed to limit the number of
fragments in the queue, but was closing the throttling ref after
submission rather than transmission so that the queue could grow without
bound sometimes.

It's been like this since the test was introduced in elastic#111933, but it
only started failing recently. I suspect until the performance
improvement in elastic#139988 landed it couldn't actually submit enough tasks
at once to cause a failure.

Closes elastic#143644

Silly test mistake: the throttle was supposed to limit the number of
fragments in the queue, but was closing the throttling ref after
submission rather than transmission so that the queue could grow without
bound sometimes.

It's been like this since the test was introduced in #111933, but it
only started failing recently. I suspect until the performance
improvement in #139988 landed it couldn't actually submit enough tasks
at once to cause a failure.

Closes #143644

Silly test mistake: the throttle was supposed to limit the number of
fragments in the queue, but was closing the throttling ref after
submission rather than transmission so that the queue could grow without
bound sometimes.

It's been like this since the test was introduced in elastic#111933, but it
only started failing recently. I suspect until the performance
improvement in elastic#139988 landed it couldn't actually submit enough tasks
at once to cause a failure.

Closes elastic#143644

Silly test mistake: the throttle was supposed to limit the number of
fragments in the queue, but was closing the throttling ref after
submission rather than transmission so that the queue could grow without
bound sometimes.

It's been like this since the test was introduced in #111933, but it
only started failing recently. I suspect until the performance
improvement in #139988 landed it couldn't actually submit enough tasks
at once to cause a failure.

Closes #143644

Silly test mistake: the throttle was supposed to limit the number of
fragments in the queue, but was closing the throttling ref after
submission rather than transmission so that the queue could grow without
bound sometimes.

It's been like this since the test was introduced in #111933, but it
only started failing recently. I suspect until the performance
improvement in #139988 landed it couldn't actually submit enough tasks
at once to cause a failure.

Closes #143644

Silly test mistake: the throttle was supposed to limit the number of
fragments in the queue, but was closing the throttling ref after
submission rather than transmission so that the queue could grow without
bound sometimes.

It's been like this since the test was introduced in elastic#111933, but it
only started failing recently. I suspect until the performance
improvement in elastic#139988 landed it couldn't actually submit enough tasks
at once to cause a failure.

Closes elastic#143644

On reading this class again a few months after elastic#139988 it took some time
to work this out. Adding a comment for the next person.

On reading this class again a few months after #139988 it took some time
to work this out. Adding a comment for the next person.

On reading this class again a few months after elastic#139988 it took some time
to work this out. Adding a comment for the next person.