GEODE-6973: Use cachelistener to synchronize typeToId with IdToType#4014
GEODE-6973: Use cachelistener to synchronize typeToId with IdToType#4014gesterzhou merged 17 commits intoapache:developfrom
Conversation
Co-authored-by: Xiaojian Zhou <gzhou@pivotal.io>
Co-authored-by: Donal Evans <doevans@pivotal.io>
Co-authored-by: Donal Evans <doevans@pivotal.io> Co-authored-by: Xiaojian Zhou <gzhou@pivotal.io>
…' into feature/GEODE-6973-2
| return newType.getTypeId(); | ||
| } finally { | ||
| // flush the tmpTypeToId map for who introduced this new pdxType | ||
| if (!tmpTypeToId.isEmpty()) { |
There was a problem hiding this comment.
Why is this finally needed? How would the tmpTypeToId not already be empty here?
There was a problem hiding this comment.
We have discussed that, it's safe to do it when the creator holds the d-lock.
The listener will only add into tmpTypeToId map now. We use it to make sure that the distribution should all finished before flushing anything into typeToId map (they stayed in tmpTypeToId map now)
There was a problem hiding this comment.
But wouldn't the line above (line 386) when we actually use the map, have cleared it? Why do we need to reclear in the finally? Why is the duplicated code needed in the finally block? Same goes for the other method...
bschuchardt
left a comment
There was a problem hiding this comment.
Is it possible to use variable names that don't begin with "tmp" and are more descriptive of what you're accomplishing? It seems like you're staging additions to other collections so maybe "pending" instead of "tmp" would be better.
|
I changed the map's name based on bruce's suggestion. |
The map name is changed to "pending"
bschuchardt
left a comment
There was a problem hiding this comment.
I'm sorry but I find this whole change set difficult to follow and think it would be pretty much impossible for a new developer to figure out. Is there any way to make this be less piecemeal, with one method throwing stuff into a collection that it's "understood" that another method will consume under some lock/synchronization? PDX already has confusing caches and this just seems to exacerbate the situation.
Co-authored-by: Donal Evans <doevans@pivotal.io> Co-authored-by: Xiaojian Zhou <gzhou@pivotal.io>
Authored-by: Donal Evans <doevans@pivotal.io>
|
@bschuchardt - To make your suggestion more concrete - would it help to move pendingTypeToId and typeToId to a separate data structure that encapsulates that functionality? IMO this whole pendingTypeToId business is essentially working around a limitation in our transactions. I would expect that if a CacheListener fires in Member A as a result of a transaction, then a |
Authored-by: Donal Evans <doevans@pivotal.io>
upthewaterspout
left a comment
There was a problem hiding this comment.
Where did all of this sample json come from? It has email address, urls in it?
How likely is it for some of these new tests to be flaky? I see things like toleratedCollisionFraction=0.01f? Is this a test with a lot of random numbers that may occasionally fail? Can we at least lock it down with a seed so that it either passes or fails consistently?
|
@upthewaterspout yes, that would help. It's like we're writing to a structure but don't want to commit the changes in the current thread. The changes need to be committed in another thread. Encapsulating the collections in another object that requires that the correct locks are obtained before transferring from pending to committed would go a long way toward making these changes more understandable without hearing Gester's presentation on the solution. |
Authored-by: Donal Evans <doevans@pivotal.io>
|
I removed those tests. You're right, they were potentially flaky and not testing any behaviour that wasn't accounted for elsewhere. As for where the sample JSON came from, it was just an edited version of an existing JSON resource used in other tests. |
|
The testJSON.txt is from ./geode-core/src/distributedTest/resources/org/apache/geode/pdx/jsonStrings/json4.txt. We can change it to dummy url and email. |
|
I will create an inner class LocalReverseMap to wrap the typeToId, enumToId, pendingTypeToId, pendingEnumToId. |
|
I created an inner class to wrap all these local maps. Pls review again. |
bschuchardt
left a comment
There was a problem hiding this comment.
that's much better - thank you
Authored-by: Donal Evans <doevans@pivotal.io>
Authored-by: Donal Evans <doevans@pivotal.io>
Thank you for submitting a contribution to Apache Geode.
In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:
For all changes:
Is there a JIRA ticket associated with this PR? Is it referenced in the commit message?
Has your PR been rebased against the latest commit within the target branch (typically
develop)?Is your initial contribution a single, squashed commit?
Does
gradlew buildrun cleanly?Have you written or updated unit tests to verify your changes?
If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?
Note:
Please ensure that once the PR is submitted, check Concourse for build issues and
submit an update to your PR as soon as possible. If you need help, please send an
email to dev@geode.apache.org.