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

fix(server) Avoid duplicate registration of StoreEventListener #2620

Open
wants to merge 10 commits into
base: master
Choose a base branch
from

Conversation

haohao0103
Copy link
Contributor

close #2618

Define initialization identifiers for storeEventListeners in AbstractBackendStoreProvider to ensure that storeEventListeners are not registered repeatedly

@dosubot dosubot bot added size:XS This PR changes 0-9 lines, ignoring generated files. store Store module labels Aug 6, 2024
Comment on lines 73 to 74
if (schemaCacheClearListened.compareAndSet(false, true) ||
vertexEdgeCacheClearListened.compareAndSet(false, true)) {
Copy link
Member

@imbajin imbajin Aug 10, 2024

Choose a reason for hiding this comment

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

Some questions:

  • we define 2 automic_param boolean A & B and try to set them to true, when to reset it?
  • why we need 2 flag to mark it? (in this context)
  • since assignment operations (=) for primitive types are atomic by default(64bit), it seems that we only need to use a volatile boolean flag to achieve the desired effect?

@Pengzna @VGalaxies

Copy link
Contributor Author

Choose a reason for hiding this comment

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

1、define 2 automic_param boolean A & B;this operation is to ensure that storeEventListener does not deliver to storeEventHub of storeProvider once in each thread. I understand that there is no need to re register during the entire Hugegraph lifecycle, so there is no reset operation; Will this miss other necessary scenarios?
2、schemaCacheClearListened for schemaCache clear , vertexEdgeCacheClearListened for vertex&edge cache;
3、 I have modified it to use the volatile+synchronized,thanks

@dosubot dosubot bot added size:M This PR changes 30-99 lines, ignoring generated files. and removed size:XS This PR changes 0-9 lines, ignoring generated files. labels Aug 12, 2024
Copy link

codecov bot commented Aug 13, 2024

Codecov Report

Attention: Patch coverage is 80.95238% with 4 lines in your changes missing coverage. Please review.

Project coverage is 38.93%. Comparing base (a038d23) to head (ceba46c).

Files Patch % Lines
...ph/backend/store/AbstractBackendStoreProvider.java 87.50% 0 Missing and 2 partials ⚠️
.../hugegraph/backend/store/BackendStoreProvider.java 0.00% 2 Missing ⚠️

❗ There is a different number of reports uploaded between BASE (a038d23) and HEAD (ceba46c). Click for more details.

HEAD has 2 uploads less than BASE
Flag BASE (a038d23) HEAD (ceba46c)
5 3
Additional details and impacted files
@@             Coverage Diff              @@
##             master    #2620      +/-   ##
============================================
- Coverage     45.17%   38.93%   -6.24%     
- Complexity      583      759     +176     
============================================
  Files           718      729      +11     
  Lines         58434    59520    +1086     
  Branches       7491     7660     +169     
============================================
- Hits          26396    23177    -3219     
- Misses        29318    33870    +4552     
+ Partials       2720     2473     -247     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

…raph/backend/store/AbstractBackendStoreProvider.java

Co-authored-by: imbajin <[email protected]>
@imbajin imbajin requested review from javeme and zyxxoo August 15, 2024 10:01
@zyxxoo
Copy link
Contributor

zyxxoo commented Aug 15, 2024

thanks for you push code for solve the problem, this is a great code, but i have some different advise for that. ohh, the transaction monitor some event happen, meawhile, the code change the state local, every instance maybe need care the event, so we should allow repeated event register; for the problem, i think the main problem maybe is the threadlocal not correct release, that make the listen not be remove

Copy link
Contributor

@javeme javeme left a comment

Choose a reason for hiding this comment

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

Thanks for your contribution, some tiny comments

@@ -105,7 +105,8 @@ private void listenChanges() {
}
return false;
};
this.graphParams().loadGraphStore().provider().listen(this.storeEventListener);
this.graphParams().loadGraphStore().provider()
.listenSchemaCacheClear(this.storeEventListener);

// Listen cache event: "cache"(invalid cache item)
this.cacheEventListener = event -> {
Copy link
Contributor

Choose a reason for hiding this comment

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

@imbajin can you share some context why we added CachedSchemaTransactionV2.java? not sure it's used in what scenarios, and can we merge V1+V2 into one class?

Copy link
Contributor

Choose a reason for hiding this comment

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

CachedSchemaTransactionV2 is the CachedSchemaTransaction corresponding to the SchemaTransaction of the pd-store version. We added a V2 to distinguish it from the previous version. Due to the inconsistency of the parameters required for construction, it is currently not easy to reuse, will be merged later...

@@ -133,7 +133,7 @@ private void listenChanges() {
}
return false;
};
this.store().provider().listen(this.storeEventListener);
this.store().provider().listenDataCacheClear(this.storeEventListener);
Copy link
Contributor

Choose a reason for hiding this comment

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

Sorry I have read the issue, but I still don't quite understand in what scenarios.the problem is encountered.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

simply put,i found that registering a listener for each transaction instance is redundant because each transaction receives events and then performs a clear operation on the schema/vertex/edge cache , i think that this is redundant.

Copy link
Contributor

Choose a reason for hiding this comment

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

Note each provider has multiple listeners, which is our design intention, because each listener wants to get notifications.
This modification looks a bit special at the moment, and we will propose a solution after we figure out the problem. Could you post the error stack if there is an error?

@@ -67,6 +67,12 @@ public interface BackendStoreProvider {

void listen(EventListener listener);

default void listenSchemaCacheClear(EventListener listener) {
Copy link
Contributor

Choose a reason for hiding this comment

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

prefer listenSchemaCacheAtMostOnce

Copy link
Contributor Author

Choose a reason for hiding this comment

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

thanks , you mean to update the method name to listenSchemaCacheAtMostOnce?

default void listenSchemaCacheClear(EventListener listener) {
}

default void listenDataCacheClear(EventListener listener) {
Copy link
Contributor

Choose a reason for hiding this comment

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

prefer listenGraphCacheAtMostOnce

@haohao0103
Copy link
Contributor Author

haohao0103 commented Aug 19, 2024

thanks for you push code for solve the problem, this is a great code, but i have some different advise for that. ohh, the transaction monitor some event happen, meawhile, the code change the state local, every instance maybe need care the event, so we should allow repeated event register; for the problem, i think the main problem maybe is the threadlocal not correct release, that make the listen not be remove

thanks , i try to understand what you mean , Indeed, there some issues with threadlocal processing,and my code did not address this problem. In addition ,I think it is indeed valuable to pay attention to events for each transaction instance; But in the current scenario,based on my understanding,this operation seems redundant because schema and vertex/edge cache are both global singleton, and it seems unnecessay to execute their operations on every transaction instance. of course ,if there are personalized scenarios that allow for reregistration of listener,it is indeed necessary and valuable.this is my idea, welcome to correct it.

Copy link

Due to the lack of activity, the current pr is marked as stale and will be closed after 180 days, any update will remove the stale label

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
inactive size:M This PR changes 30-99 lines, ignoring generated files. store Store module
Projects
Status: In progress
5 participants