When is removeProxy actually called?

[sujitdmello]

I implemented a custom ProxyManager that wraps the DAPR state management API. But I am not clear when bucket.removeProxy() should be called. I am deleting the state associated with the bucket in the implementation of the call, but I am unclear when to call this method in the application.

I would assume that if the bucket limits change, the state should be deleted, but does this mean that the code should monitor bucket configuration changes and if detected, call the bucket.removeProxy() method?

Or is the strategy to use bucket.replaceConfiguration()?

[vladimir-bukhtoyarov]

Hello @sujitdmello

ProxyMenager#removeProxy is never called by library itself. It was added in order to simplify unit-tests.

You should use replaceConfiguration when you need to reconfigure buckets. Also if your limits are stored just in config file then implicit configuration replacement can be used.

[sujitdmello]

Thank you!

[vladimir-bukhtoyarov]

@sujitdmello

Also I recommend to test your integration with DAPR via extending this test-base. TCK is available in maven central with special type test-jar

        <dependency>
            <groupId>com.bucket4j</groupId>
            <artifactId>bucket4j-core</artifactId>
            <version>${bucket4j.version}</version>
            <type>test-jar</type>
            <scope>test</scope>
        </dependency>

AbstractDistributedBucketTest contains multiple checks for many aspects of distributed bucket implementation.

[sujitdmello]

Tried the tests against the custom ProxyManager but these tests keep failing:

testTryConsumeWithLimit java.lang.AssertionError: Actual rate 60.275 is greater then permitted rate 16.667
testParallelInitialization: java.lang.AssertionError:
Expected :6
Actual :9
testTryConsume: java.lang.AssertionError: Actual rate 62.775 is greater then permitted rate 16.667

Tried the tests with the mock ProxyManager and the same tests failed as well.

Any thoughts on what I may be doing wrong? Thanks!

[vladimir-bukhtoyarov]

@sujitdmello

1

CompareAndSwapBasedProxyManagerMock is not designed to be used in multithreaded tests(anyway I will fix this moment).

2

testTryConsumeWithLimit java.lang.AssertionError: Actual rate 60.275 is greater then permitted rate 16.667

This test is addressed for checking of concurrency aspects.

The numbers 60.275 / 16.667 = 3.61, where 3.61 is close to parrallel threads count 4, show that your implementation has serrious problems with parallel execution.

3

testParallelInitialization: java.lang.AssertionError: Expected :6 Actual :9

Is about concurrency too.

It simulates the situation when bucket is initilaized in parrallel from many places, for example in case of many nodes are restarting. The expected behavios is following: only one thread is allowed to create bucket, other threads should reuse bucket that was created by first winner, but numbers show that threads which had come after first winner just rewrited already created bucket and information about consumed tokens lost.

---

In conclusiion: your implementation needs to be enhanced in concurrency aspect.

[sujitdmello]

Thanks for the tips and advice - I addressed the concurrency issue with regards to managing data conflicts in Dapr state using eventual consistency and first-write wins and now the results are better:

[INFO] Running com.service.DaprProxyManagerStressTest
Remaining tokens = 3
Tokens per bandwidth = [3, 9]
Remaining tokens = 2
Tokens per bandwidth = [2, 8]
Remaining tokens = 1
Tokens per bandwidth = [1, 7]
Remaining tokens = 0
Tokens per bandwidth = [0, 6]
Consumed 84 tokens in the 5047 millis, actualRatePerSecond=16.644, permitted rate=16.667
Consumed 83 tokens in the 5006 millis, actualRatePerSecond=16.581, permitted rate=16.667
[INFO] Tests run: 15, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 10.115 s - in com.service.DaprProxyManagerStressTest