-
Notifications
You must be signed in to change notification settings - Fork 522
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
base: master
Are you sure you want to change the base?
Conversation
support disable rocksdb auto compaction through configuration
if (schemaCacheClearListened.compareAndSet(false, true) || | ||
vertexEdgeCacheClearListened.compareAndSet(false, true)) { |
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.
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 avolatile
boolean flag to achieve the desired effect?
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.
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
...raph-core/src/main/java/org/apache/hugegraph/backend/store/AbstractBackendStoreProvider.java
Outdated
Show resolved
Hide resolved
Codecov ReportAttention: Patch coverage is
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. |
...raph-core/src/main/java/org/apache/hugegraph/backend/store/AbstractBackendStoreProvider.java
Outdated
Show resolved
Hide resolved
…raph/backend/store/AbstractBackendStoreProvider.java Co-authored-by: imbajin <[email protected]>
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 |
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.
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 -> { |
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.
@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?
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.
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); |
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.
Sorry I have read the issue, but I still don't quite understand in what scenarios.the problem is encountered.
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.
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.
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.
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) { |
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.
prefer listenSchemaCacheAtMostOnce
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.
thanks , you mean to update the method name to listenSchemaCacheAtMostOnce?
default void listenSchemaCacheClear(EventListener listener) { | ||
} | ||
|
||
default void listenDataCacheClear(EventListener listener) { |
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.
prefer listenGraphCacheAtMostOnce
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. |
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 |
close #2618
Define initialization identifiers for storeEventListeners in AbstractBackendStoreProvider to ensure that storeEventListeners are not registered repeatedly