-
Notifications
You must be signed in to change notification settings - Fork 3.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Avoid potentially blocking calls to metadata on critical threads #12339
Conversation
...common/src/main/java/org/apache/pulsar/broker/authorization/PulsarAuthorizationProvider.java
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good. Left some minor comments.
...common/src/main/java/org/apache/pulsar/broker/authorization/PulsarAuthorizationProvider.java
Outdated
Show resolved
Hide resolved
pulsar-broker/src/main/java/org/apache/pulsar/broker/service/AbstractTopic.java
Outdated
Show resolved
Hide resolved
pulsar-broker/src/main/java/org/apache/pulsar/broker/service/AbstractTopic.java
Outdated
Show resolved
Hide resolved
...ar-broker/src/main/java/org/apache/pulsar/broker/service/persistent/DispatchRateLimiter.java
Outdated
Show resolved
Hide resolved
@michaeljmarshall Please help review again |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great Job!
… threads (#12339) (#12340) * Avoid potentially blocking calls to metadata on critical threads (#12339) * Fixed NPE * Addressed comments * Fixed issue with mocked tests * Fixed behavior in BacklogQuotaManager to be like before * Fixed AuthorizationProducerConsumerTest * Fixed PersistentTopicTest * Fixed PersistentTopicTest
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Left one question about exception handling.
policies = brokerService.pulsar().getPulsarResources().getNamespaceResources().getPoliciesIfCached( | ||
TopicName.get(topic).getNamespaceObject()) | ||
.orElseGet(() -> new Policies()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see this was added in the most recent commit to help with a mocked test. This block doesn't throw any checked exceptions. Do we expect RuntimeExceptions
from it? If we do, should we wrap other similar code blocks in this PR with try and catch? If we don't, perhaps we should update the test.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Many tests are using mocked versions which would throw exception... then the try/catch was the thing that was making all these tests to work..
…che#12339) * Avoid potentially blocking calls to metadata on critical threads * Fixed log arguments order * Addressed comments * Fixed mock in PersistentSubscriptionTest * Fixed issue in mocked tests * Fixed test that was force policies modification under the hood (cherry picked from commit c0e87c0)
…che#12339) * Avoid potentially blocking calls to metadata on critical threads * Fixed log arguments order * Addressed comments * Fixed mock in PersistentSubscriptionTest * Fixed issue in mocked tests * Fixed test that was force policies modification under the hood
…ause org.apache.pulsar.broker.admin.AdminApiTest#testTopicStatsLastExpireTimestampForSubscription failing.
* Revert "[fix][proxy] Fix client service url (#16834)" This reverts commit 10b4e99. * Revert "[Build] Use grpc-bom to align grpc library versions (#15234)" This reverts commit 99c93d2. * Revert "upgrade aircompressor to 0.20 (#11790)" This reverts commit 5ad16b6. * Revert "[Branch-2.7] Fixed deadlock on metadata cache missing while doing checkReplication (#12484)" This reverts commit 32fe228. * Revert changes of PersistentTopic#getMessageTTL in #12339. Co-authored-by: JiangHaiting <janghaiting@apache.org>
Motivation
We have several places that are accessing the namespace policies in a synchronous way from the critical IO threads of the broker. These accesses are almost always non-blocking calls since the policies are already cached (given that the topic was just loaded and the policies were checked then).
There are few corner cases though in which we would incur in cache misses and that could have a big impact, up to result in a complete deadlock, if we exhaust all the threads in the ordered executors.
For example this can happen when there are thousands of producers/consumers connecting and there is a change in the policies that triggers a cache invalidation.
We must have no potentially blocking calls in the critical path.