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

Move setDefaultProperties in the static init #40250

Merged
merged 1 commit into from
Apr 24, 2024
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
@@ -1,6 +1,7 @@
package io.quarkus.narayana.jta.deployment;

import static io.quarkus.deployment.annotations.ExecutionTime.RUNTIME_INIT;
import static io.quarkus.deployment.annotations.ExecutionTime.STATIC_INIT;

import java.util.List;
import java.util.Map;
Expand Down Expand Up @@ -137,6 +138,16 @@ public void build(NarayanaJtaRecorder recorder,
builder.addBeanClass(TransactionalInterceptorNotSupported.class);
additionalBeans.produce(builder.build());

// This must be done before setNodeName as the code in setNodeName will create a TSM based on the value of this property
recorder.disableTransactionStatusManager();
recorder.setNodeName(transactions);
Copy link
Member

@Sanne Sanne Apr 24, 2024

Choose a reason for hiding this comment

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

Did someone check if we end up having the same node names across all instances?

Copy link
Contributor

Choose a reason for hiding this comment

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

I don't think Amos actually changed these lines, the diff is showing because the other lines were reordered. I believe that the only change is to move the code that sets up the defaultProperties into a @record(STATIC_INIT) build step (he added the new method public void setProperties(NarayanaJtaRecorder recorder). Is that correct @zhfeng ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah, it is. Thanks @mmusgrov !

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@Sanne I don't understand here. What are you mean all intances?

Copy link
Member

@Sanne Sanne Apr 29, 2024

Choose a reason for hiding this comment

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

By "instances" I mean instances of the application. If I start 10 copies of the same Quarkus application, it's my understanding that it's essential that they are assigned a different Node Name - or at least to offer the possibility of users to configure different node names.

By seeing the setNodeName invoked on a build-time recorder, it makes me worry that this configuration setting wouldn't be honoured at runtime: I'm suggesting to please check this as it would be a grave mistake.

Copy link
Contributor Author

@zhfeng zhfeng Apr 29, 2024

Choose a reason for hiding this comment

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

Hmm, no, setNodeName is at runtime. And this commit has been reverted in

Copy link
Member

Choose a reason for hiding this comment

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

Ok, thanks.

recorder.setDefaultTimeout(transactions);
recorder.setConfig(transactions);
}

@BuildStep
@Record(STATIC_INIT)
public void setProperties(NarayanaJtaRecorder recorder) {
//we want to force Arjuna to init at static init time
Properties defaultProperties = PropertiesFactory.getDefaultProperties();
//we don't want to store the system properties here
Expand All @@ -145,11 +156,6 @@ public void build(NarayanaJtaRecorder recorder,
defaultProperties.remove(i);
}
recorder.setDefaultProperties(defaultProperties);
Copy link
Member

Choose a reason for hiding this comment

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

With this, in the case of a native executable, the properties will be set at build time. This is what you want for all of them?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good point - @mmusgrov do know if there is any property we don't want to set at build time?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

If we only expect to apply these properties at run time. It has to revert this commit.

Copy link
Contributor

Choose a reason for hiding this comment

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

I'm not sure but it seems restrictive, Narayana has many useful configuration options which were added to give users runtime control over how the TM operates.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

OK, I open #40310 and it looks good to make BeanPopulator to init at runtime. So we don't need any change on narayana side.

// This must be done before setNodeName as the code in setNodeName will create a TSM based on the value of this property
recorder.disableTransactionStatusManager();
recorder.setNodeName(transactions);
recorder.setDefaultTimeout(transactions);
recorder.setConfig(transactions);
}

@BuildStep
Expand Down
Loading