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

Conversation

@quarkus-bot quarkus-bot bot added the area/narayana Transactions / Narayana label Apr 24, 2024
@gastaldi
Copy link
Contributor

/cc @mmusgrov

@gastaldi gastaldi requested a review from gsmet April 24, 2024 15:05
Copy link

quarkus-bot bot commented Apr 24, 2024

Status for workflow Quarkus CI

This is the status report for running Quarkus CI on commit aef89d6.

✅ The latest workflow run for the pull request has completed successfully.

It should be safe to merge provided you have a look at the other checks in the summary.

You can consult the Develocity build scans.


Flaky tests - Develocity

⚙️ JVM Tests - JDK 17

📦 extensions/smallrye-reactive-messaging-kafka/deployment

io.quarkus.smallrye.reactivemessaging.kafka.deployment.dev.KafkaDevServicesDevModeTestCase.sseStream - History

  • Assertion condition defined as a Lambda expression in io.quarkus.smallrye.reactivemessaging.kafka.deployment.dev.KafkaDevServicesDevModeTestCase Expecting size of: [] to be greater than or equal to 2 but was 0 within 10 seconds. - org.awaitility.core.ConditionTimeoutException
org.awaitility.core.ConditionTimeoutException: 
Assertion condition defined as a Lambda expression in io.quarkus.smallrye.reactivemessaging.kafka.deployment.dev.KafkaDevServicesDevModeTestCase 
Expecting size of:
  []
to be greater than or equal to 2 but was 0 within 10 seconds.
	at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167)
	at org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
	at org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)

⚙️ JVM Tests - JDK 21

📦 extensions/smallrye-reactive-messaging-kafka/deployment

io.quarkus.smallrye.reactivemessaging.kafka.deployment.dev.KafkaDevServicesDevModeTestCase.sseStream - History

  • Assertion condition defined as a Lambda expression in io.quarkus.smallrye.reactivemessaging.kafka.deployment.dev.KafkaDevServicesDevModeTestCase Expecting size of: [] to be greater than or equal to 2 but was 0 within 10 seconds. - org.awaitility.core.ConditionTimeoutException
org.awaitility.core.ConditionTimeoutException: 
Assertion condition defined as a Lambda expression in io.quarkus.smallrye.reactivemessaging.kafka.deployment.dev.KafkaDevServicesDevModeTestCase 
Expecting size of:
  []
to be greater than or equal to 2 but was 0 within 10 seconds.
	at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167)
	at org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
	at org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)

@@ -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.

Copy link
Contributor

@mmusgrov mmusgrov left a comment

Choose a reason for hiding this comment

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

This is a much more insightful fix than the ones suggested on the issue, I approve.

@gastaldi gastaldi merged commit aaf9d01 into quarkusio:main Apr 24, 2024
41 checks passed
@quarkus-bot quarkus-bot bot added this to the 3.11 - main milestone Apr 24, 2024
@gastaldi
Copy link
Contributor

Should we backport this too?

@zhfeng
Copy link
Contributor Author

zhfeng commented Apr 24, 2024

@gastaldi yeah, at least for 3.8.x

@@ -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.

@Sanne
Copy link
Member

Sanne commented Apr 28, 2024

This comment of mine here is worrying me, did someone check it?

@gsmet
Copy link
Member

gsmet commented Apr 29, 2024

This change was reverted in #40334 .

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/narayana Transactions / Narayana triage/flaky-test
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants