Skip to content
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

[Issue 12894] Only refresh metadata if path is already in cache after write. #12896

Merged
merged 1 commit into from
Nov 30, 2021

Conversation

Jason918
Copy link
Contributor

@Jason918 Jason918 commented Nov 19, 2021

Fixes #12894

Motivation

See #12894

Modifications

Only refresh metadata if path is already in cache after write.

Verifying this change

  • Make sure that the change passes the CI checks.

(Please pick either of the following options)

This change is already covered by existing tests, such as (please describe tests).

Does this pull request potentially affect one of the following parts:

If yes was chosen, please highlight the changes

  • Dependencies (does it add or upgrade a dependency): (no)
  • The public API: (no)
  • The schema: (no)
  • The default values of configurations: (no)
  • The wire protocol: (no)
  • The rest endpoints: (no)
  • The admin cli options: (no)
  • Anything that affects deployment: (no)

Documentation

Check the box below and label this PR (if you have committer privilege).

Need to update docs?

  • no-need-doc
    bug fix.

@Jason918
Copy link
Contributor Author

@merlimat PTAL.
We have dozens of MetadataCacheImpl instances in AbstractMetadataStore#metadataCaches.
Each of these MetadataCacheImpl have different type of object to cache, so we can't refresh them all with the same path.

@@ -331,6 +331,7 @@ public void insertionOutsideCacheWithGenericType(String provider, Supplier<Strin
});

String key1 = newKey();
objCache.get(key1).join();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is forcing the key to be in the cache, but the test was expressly trying to check the condition in which it was not.

Copy link
Contributor Author

@Jason918 Jason918 Nov 20, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changed the test to updateOutsideCacheWithGenericType for now.

I think we can implement insertionOutsideCacheWithGenericType by make a path pattern registration or add a method like accept(path) for each MetadataStore instance, which implies the metadata store could deserialization this value, and the path indeed should be cached in this metadata store.

* @param path the path of the object in the metadata store
* @return true if the path exists.
*/
boolean existsInCache(String path);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wouldn't add a new method in the API that we only are going to be using internally.

Two solutions:

  1. There is already MetadataCache.getIfCached()
  2. MetadaCache.refresh() implementation should take care of it internally.

Copy link
Contributor Author

@Jason918 Jason918 Nov 20, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The only reason I am not using MetadataCache.getIfCached() is it would block and wait for current load future is completed.

I am taking solution 2. It would not be "refresh" if we have not already loaded the path object, right?
Although, it may change some old behaviors.

@Jason918
Copy link
Contributor Author

@merlimat please help take a look?

@Jason918
Copy link
Contributor Author

@315157973 Here is the fix of #12909, PTAL

objCache.synchronous().invalidate(path);
objCache.synchronous().refresh(path);
// Refresh object of path if only it is cached before.
if (objCache.getIfPresent(path) != null) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm just wondering if there's a possibility for races.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we should move this block into a dedicated method of objCache

objCache.synchronous().invalidateAndRefreshIfPresent(path)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm just wondering if there's a possibility for races.

No, it's ok to miss a refresh or duplicate a refresh. Worst case is you have to do an extra loading when calling get.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we should move this block into a dedicated method of objCache

objCache.synchronous().invalidateAndRefreshIfPresent(path)

It's a bit of trouble to do this, because objCache is an instance of class com.github.benmanes.caffeine.cache.AsyncCacheLoader , which is in a dependent lib.

objCache.synchronous().invalidate(path);
objCache.synchronous().refresh(path);
// Refresh object of path if only it is cached before.
if (objCache.getIfPresent(path) != null) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we should move this block into a dedicated method of objCache

objCache.synchronous().invalidateAndRefreshIfPresent(path)

@shoothzj
Copy link
Member

comment #12788 for link

@Jason918
Copy link
Contributor Author

@eolivelli PTAL. Thanks

@Jason918
Copy link
Contributor Author

@merlimat PTAL. Thanks.

And to implement the origin "insertionOutsideCacheWithGenericType", I think we can add a path pattern registration or add a method like accept(path) for each MetadataStore instance, which implies the metadata store could deserialization this value, and the path indeed should be cached in this metadata store no matter how it's updated.
What do you think?

@lhotari lhotari dismissed eolivelli’s stale review November 30, 2021 21:09

Review comments were addressed. This fixes an urgent issue in master branch.

@lhotari lhotari merged commit 2b939b7 into apache:master Nov 30, 2021
@eolivelli
Copy link
Contributor

+1

zeo1995 pushed a commit to zeo1995/pulsar that referenced this pull request Dec 1, 2021
* up/master: (75 commits)
  [website][upgrade]feat: website upgrade / docs migration - 2.5.1 Get Started/Concepts and Architecture/Pulsar Schema (apache#13030)
  Fix environment variable assignment in startup scripts (apache#13025)
  update 2.8.x (apache#13029)
  [Doc] add tips for Pulsar tools (apache#13044)
  Suggest to use tlsPort instead of deprecated TlsEnable (apache#13039)
  Integration tests for function-worker rebalance and drain operations. (apache#13058)
  fix(functions): missing runtime set in GoInstanceConfig (apache#13031)
  [pulsar-admin] Add get-replicated-subscription-status command for topic (apache#12891)
  [Broker] Consider topics in pulsar/system namespace as system topics (apache#13050)
  Fix typo: correct sizeUint to sizeUnit (apache#13040)
  fix-12894 (apache#12896)
  Don't attempt to delete pending ack store unless transactions are enabled (apache#13041)
  [Perf] Evaluate the current protocol version once (apache#13045)
  Fix Issue apache#12885, Unordered consuming case in Key_Shared subscription (apache#12890)
  [broker]Optimize topicMaxMessageSize with topic local cache. (apache#12830)
  [PIP-105] Part-2 Support pluggable entry filter in Dispatcher (apache#12970)
  [website] Modify admin-api-topic.md document (apache#12996)
  add missed import (apache#13037)
  [metadata] Add RocksdbMetadataStore (apache#12776)
  [C] Add pulsar_client_subscribe_multi_topics and pulsar_client_subscribe_pattern (apache#12965)
  ...

# Conflicts:
#	site2/website-next/docusaurus.config.js
#	site2/website-next/versioned_sidebars/version-2.6.1-sidebars.json
#	site2/website-next/versions.json
fxbing pushed a commit to fxbing/pulsar that referenced this pull request Dec 19, 2021
Co-authored-by: Jiang Haiting <jianghaiting@didichuxing.com>
@codelipenghui codelipenghui added cherry-picked/branch-2.9 Archived: 2.9 is end of life and removed cherry-picked/branch-2.9 Archived: 2.9 is end of life release/2.9.2 labels Dec 21, 2021
@congbobo184 congbobo184 added cherry-picked/branch-2.9 Archived: 2.9 is end of life release/2.9.4 labels Nov 9, 2022
congbobo184 pushed a commit to congbobo184/pulsar that referenced this pull request Nov 9, 2022
Co-authored-by: Jiang Haiting <jianghaiting@didichuxing.com>
(cherry picked from commit 2b939b7)
congbobo184 pushed a commit that referenced this pull request Nov 9, 2022
Co-authored-by: Jiang Haiting <jianghaiting@didichuxing.com>
(cherry picked from commit 2b939b7)
congbobo184 pushed a commit that referenced this pull request Nov 26, 2022
Co-authored-by: Jiang Haiting <jianghaiting@didichuxing.com>
(cherry picked from commit 2b939b7)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cherry-picked/branch-2.9 Archived: 2.9 is end of life doc-not-needed Your PR changes do not impact docs release/2.9.4
Projects
None yet
Development

Successfully merging this pull request may close these issues.

ContentDeserializationException and warning logs in metadata store.
7 participants