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
ISPN-11541 Add internal metadata to write commands #8113
ISPN-11541 Add internal metadata to write commands #8113
Conversation
ae96055
to
919a3c7
Compare
919a3c7
to
38d1bd6
Compare
Should we perfack this ? |
@pruivo Is this PR still valid in light of #7858 (comment)?
|
yes. I have already the |
run performance tests please |
How far down the line are we talking? This touches a lot of classes, so it makes it somewhat of a moving target for us working in the same area. |
The persistence is missing. My plans are to open a PR after this one. |
//TODO! why adding version for replace? | ||
//if (!configuration.transaction().transactionMode().isTransactional()) { | ||
// interceptorChain.appendInterceptor(createInterceptor(new VersionInterceptor(), VersionInterceptor.class), false); | ||
//} |
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.
Is this still meant to be commented?
If we're removing this, should it be a separate commit/Jira?
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 forgot to ask @gustavonalle about it. Is the VersionInterceptor still needed?
It sets some version for the replace commands and I didn't find any usage of that version.
It breaks the xsite tests if non-tx cache (on site 1) backups to a tx cache (on site 2).
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 am not sure TBH. This is a relic from the compat mode times
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.
oh... I found a failure... EmbeddedRestMemcachedHotRodTest fails without it.
I need to drop the version in the receiver site... bah...
@@ -733,6 +733,7 @@ protected IntSet getOwnedSegments(ConsistentHash consistentHash) { | |||
InternalMetadataImpl metadata = new InternalMetadataImpl(e); | |||
PutKeyValueCommand put = commandsFactory.buildPutKeyValueCommand(e.getKey(), e.getValue(), segmentId, | |||
metadata, STATE_TRANSFER_FLAGS); | |||
put.setInternalMetadata(e.getInternalMetadata()); |
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.
We should add MetaParamsInternalMetadata
to CommandsFactory#buildPutKeyValueCommand
.
Similarly, I noticed that the internal metadata is not set in ProtobufMetadataManagerInterceptor
. How are internal commands handled by xsite, should this be set there as well?
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.
We should add
MetaParamsInternalMetadata
toCommandsFactory#buildPutKeyValueCommand
.
I didn't add it because I want to try to avoid touching too much interface... it would require a lot of changes everywhere and most of the places, the value is null
.
Similarly, I noticed that the internal metadata is not set in
ProtobufMetadataManagerInterceptor
.
Is it needed? and set it to what exactly? (sorry, no idea what ProtobufMetadataManagerInterceptor is)
The current xsite impl doesn't use it.
In the new one, the internal metadata is set by the primary owner before replicating it to the backup owners.
It is also used by the state transfer so the joiners can set the correct versions.
core/src/main/java/org/infinispan/xsite/ClusteredCacheBackupReceiver.java
Outdated
Show resolved
Hide resolved
@@ -20,6 +24,7 @@ | |||
long flags; | |||
DataConversion keyDataConversion; | |||
DataConversion valueDataConversion; | |||
Map<Object, MetaParamsInternalMetadata> internalMetadataMap; |
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.
Is there no way we can trim this somehow... a ConcurrentHashMap for every functional command is a lot of bloat. Why not just 1 like we did with the other metadata?
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.
The internal metadata is stored per key. Each key will have a different version.
I have looked through the code and for the most part it seems fine. However it is not easy reviewing knowing that nearly all of the changes in this PR are going to change. Let's get the the follow ups in quickly (I'll make sure I'm timely with a review). I'll hold off rebasing my marshalling branch until then and progress locally, as it's too much of a moving target otherwise due to all of the areas this touches. Plus a simple class containing the two versions will make my life simpler in the long run. |
@@ -30,13 +35,15 @@ protected AbstractWriteManyCommand(CommandInvocationId commandInvocationId, | |||
this.flags = params.toFlagsBitSet(); | |||
this.keyDataConversion = keyDataConversion; | |||
this.valueDataConversion = valueDataConversion; | |||
this.internalMetadataMap = new ConcurrentHashMap<>(); |
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.
Can we use an immutable empty list here?
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.
no, otherwise I will get an UnsupportedException
when I try to put metadata there.
It can be null
but then I will have to put some null
checks before get/put and do a proper synchronization around it. I would rather not do it.
38d1bd6
to
11252ee
Compare
@ryanemerson updated! |
@diegolovison Perk ack didn't run for some reason. Can you take a look? |
d853df1
to
c577dd6
Compare
Performance tests didn't finish successfully. @diegolovison, can you review it? Additional info: |
run performance tests please |
Performance tests didn't finish successfully. @diegolovison, can you review it? Additional info: |
run performance tests please |
perf looks good @ryanemerson |
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.
Two very minor things. I'm looking at the follow up now
core/src/main/java/org/infinispan/remoting/responses/PrepareResponse.java
Outdated
Show resolved
Hide resolved
core/src/main/java/org/infinispan/remoting/responses/PrepareResponse.java
Outdated
Show resolved
Hide resolved
c577dd6
to
7438ff6
Compare
7438ff6
to
2e3d496
Compare
Thanks @pruivo |
https://issues.redhat.com/browse/ISPN-11541