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

Compute XA recovery nodes from node identifier by default #143

Merged
merged 1 commit into from
Jun 21, 2024

Conversation

graben
Copy link
Contributor

@graben graben commented May 23, 2024

It's better to compute the XA recovery nodes from node identifier value, if not explicitly set. Avoids to set it twice if using custom node name.

@graben
Copy link
Contributor Author

graben commented Jun 7, 2024

Hi @geoand,

there are quite a lot of PRs open for long time. Could you please have a look at them if possible?

Thanks
Benjamin

@geoand
Copy link
Member

geoand commented Jun 7, 2024

Hi,

Unfortunately I know very little about Narayana, so I am not the best person to review those

@graben
Copy link
Contributor Author

graben commented Jun 7, 2024

Maybe I should ask @mmusgrov for his opinion to this specific task? But later on I need someone with commit rights ;)

@geoand
Copy link
Member

geoand commented Jun 7, 2024

Sounds reasonable :)

@mmusgrov
Copy link

The node identifier should be unique (amongst instances that wish to share resource managers or objectstores) as explained in narayana config bean javadoc. Apart from that restriction you can use whatever you like.

@mmusgrov
Copy link

there are quite a lot of PRs open for long time. Could you please have a look at them if possible?

@graben we no longer get involved with the snowdrop project, for a number of years now, and I'm not sure who would be the best person to ask but I'd suggest that you take a look at the project commit history or the PR merge history.

@mmusgrov
Copy link

there are quite a lot of PRs open for long time. Could you please have a look at them if possible?

@graben we no longer get involved with the snowdrop project, for a number of years now, and I'm not sure who would be the best person to ask but I'd suggest that you take a look at the project commit history or the PR merge history.

That said, your PRs updating various versions of dependencies all look good but can someone from the snowdrop team run some tests to verify that the new versions still work with snowdrop? @cmoulliard can you help Benjamin determine who to ping to get his PRs reviewed please?

@graben
Copy link
Contributor Author

graben commented Jun 19, 2024

Hi @mmusgrov, thanks for your comments. I think the question you might be a good person to ask according to this PR is the change that node identifier and xa recovery nodes should be in sync by default. There are actually two different configuration points in snowdrop integration of Narayana that the user is in charge to keep them in sync. Can you confirm that the assumption is right that changing the default to a smart sync is correct?

@mmusgrov
Copy link

They should already be kept in sync: TxControl takes the value from the config bean.

Copy link

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

Apologies Benjamin, I misunderstood what this PR was proposing. Now that I've studied the proposed changes I am able to comment on it.

@@ -128,7 +128,7 @@ public class NarayanaProperties {
/**
* XA recovery nodes.
*/
private List<String> xaRecoveryNodes = List.of("1");
private List<String> xaRecoveryNodes = List.of();

Choose a reason for hiding this comment

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

Nice, I agree that it should not default to "1".

@@ -67,6 +67,9 @@ private void setNodeIdentifier(String nodeIdentifier) {
}

private void setXARecoveryNodes(List<String> xaRecoveryNodes) {
if (xaRecoveryNodes.isEmpty()) {
xaRecoveryNodes = List.of(getPopulator(CoreEnvironmentBean.class).getNodeIdentifier());

Choose a reason for hiding this comment

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

I think if the caller (ie the user via the properties) is asking for no "bottom up" recovery (xaRecoveryNodes tells narayana which orphaned XA resources it should try to recover) then this code should be respecting that choice. If you want it to be explicit you could log an info message here, but I'd just respect the config and not try to override it.

Choose a reason for hiding this comment

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

If you do apply a property override then it would be a change in behaviour and users would need to be aware of that. Could you point me at the snowdrop documentation about this property.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

As far as I know the only doc is the readme.md. But there might exist more for the internal Redhat fork?

Copy link

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

On further thought, it is better to have resource recovery by default, which is what your PR does, than supporting users that do not want any resource recovery. Therefore I am approving of the change.

@geoand geoand merged commit 275ac77 into snowdrop:main Jun 21, 2024
2 checks passed
@graben graben deleted the xanodes branch June 21, 2024 06:06
@mmusgrov
Copy link

@geoand and @graben since there appear to be no docs, can we include a release note for this change (there is no associated issue anywhere for me to attach the release note). Something like:

With this change it is no longer possible to disable "bottom up" resource recovery. Although that is a good thing in most use cases, it does mean it cannot be disabled. Note that bottom up recovery consumes connection resources and if it were to be disabled the system admin/management would need to factor in any potential issues with resource locks for in-doubt branches. Note that WildFly takes the automatic recovery route too, like this PR does, but then again WildFly is an app server.

The reason I think it is worth mentioning to users is that I have seen questions asking how to disable recovery, for example I believe Quarkus offers the option. The last sentence about WildFly may not be appropriate for Spring Boot docs.

@geoand
Copy link
Member

geoand commented Jun 21, 2024

Sure thing!

@jacobdotcosta could you kick off a release please?

@mmusgrov
Copy link

@geoand @jacobdotcosta What about the other open PRs that are upgrading dependencies, @graben needs those too.

@geoand
Copy link
Member

geoand commented Jun 25, 2024

Merged :)

@geoand
Copy link
Member

geoand commented Jun 25, 2024

@jacobdotcosta if you can do a release (3.2.0), that would be great

@graben
Copy link
Contributor Author

graben commented Jun 25, 2024

Please hold release until update to Camel 4.4.3 is done (under vote since Sunday evening)

@geoand
Copy link
Member

geoand commented Jun 25, 2024

Understood, thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants