Feature/bypass filter

[umairk79]

Add capability to bypass calls and not to use limiter algorithm if the provided predicate criteria is met

[fedorka]

Suggested change

	private Predicate<ContextT> bypassResolver = (context) -> false;
	private static final Predicate<ContextT> ALWAYS_FALSE = (context) -> false;
	private Predicate<ContextT> bypassResolver = ALWAYS_FALSE;

[fedorka]

Suggested change

	this.bypassResolver = bypassResolver.or(shouldBypass);
	if(this.bypassResolver == ALWAYS_FALSE) {
	this.bypassResolver = shouldBypass;
	} else {
	this.bypassResolver = bypassResolver.or(shouldBypass);
	}

Since this is on the hot path for calls, let's optimize away the default case instead of hoping that the JVM is able to do it later.

[umairk79]

This is the builder method. The else condition will be skipped everytime because this.bypassResolver is aways equal to ALWAYS_FALSE in your suggestion.

[umairk79]

Read your code wrong. Applying suggestion.

[fedorka]

Nit: this for-loop runs once 😛

[umairk79]

It's meant to run once because the partition for batch calls is 0.1 * 10 = 1, where 10 is the total limit.

[fedorka]

To be very clear about the behavior, let's add

Suggested change

	}
	// Verify that bypassed requests are able to proceed even when the limiter is full
	Assert.assertFalse(limiter.acquire("live").isPresent());
	Assert.assertEquals(10, limiter.getInflight());
	Assert.assertTrue(limiter.acquire("admin").isPresent());
	Assert.assertEquals(10, limiter.getInflight());
	}

I understand that we've effectively covered that above, but this will be easier to understand for someone new to the codebase. It also helps defend against a setup issue (eg: if the limit is increased).

[umairk79]

Added extra check. This behavior is also validated for simple limiters in another test.