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

Tests are failing when running on M1 Mac #57

Closed
onobc opened this issue Aug 9, 2022 · 3 comments
Closed

Tests are failing when running on M1 Mac #57

onobc opened this issue Aug 9, 2022 · 3 comments
Assignees
Milestone

Comments

@onobc
Copy link
Collaborator

onobc commented Aug 9, 2022

Steps to reproduce: Run gradle clean build on an M1 Mac.

Possible cause: Pulsar image running super slow because of M1 Mac?

Workaround: Modify the image used in https://github.com/spring-projects-experimental/spring-pulsar/blob/749f2dbb5e386f77e842af2ece547fbdc0e8f84f/spring-pulsar/src/test/java/org/springframework/pulsar/core/AbstractContainerBaseTests.java#L24
with

static final DockerImageName PULSAR_IMAGE = DockerImageName.parse("kezhenxu94/pulsar").asCompatibleSubstituteFor("apachepulsar/pulsar");

Work items

  1. Understand what the root cause is. What is in the alternative image that makes it work? Is there some other change we should be considering or is this just the "M1 support in general is still catching up" category?
  2. Temporary stop-gap so that other users do not run into this, we could implement the above workaround automatically via Junit5 @EnabledOnOs annotation (one for M1 and one for all others).
@alpreu
Copy link
Contributor

alpreu commented Aug 10, 2022

I believe the root cause is that the standard Pulsar image running through emulation is very slow. This leads to Testcontainers startup check to time out, thus stopping further test execution.

The issue around offering ARM based images can be found here:
apache/pulsar#12944

And the experimental image above was built using this PR:
apache/pulsar#14005

I tried to re-ignite the discussion on the mailing list around this topic and looped in colleagues as well.

For the time being, I think it's a good idea to enable the workaround using the JUnit annotation as you described above.

Edit: After some further investigation this is not as straightforward. The JUnit annotation only works on a (@test) method level, not block-level. So we cannot keep the shared testcontainer as it is. The second problem is that the architecture. parameter of the annotation internally uses System.getProperty("os.arch"). Because this is depending on the JDK, and not implemented on the actual system level, this can return x86_64 even for M1 macs (see https://stackoverflow.com/questions/69497067/java-sdk-reporting-wrong-architecture-on-mac-m1).

Maybe the best way is to let users set an environment variable if they are using the M1 chip and exchange the image name when it's set.

@onobc onobc added this to the 0.1.0-M1 milestone Aug 23, 2022
@onobc onobc self-assigned this Aug 23, 2022
@onobc
Copy link
Collaborator Author

onobc commented Aug 26, 2022

Great find @alpreu - thanks for digging in.

Maybe we can put a custom "condition" in the static initializer to determine image name.

	static {
		MyCustomCondition isMacCondition = ...
		if (isMacCondition) {
			image = "";
		}
		else {
			image = "";
		}
		DockerImageName PULSAR_IMAGE = DockerImageName.parse("apachepulsar/pulsar:2.10.1");
		PULSAR_CONTAINER = new PulsarContainer(PULSAR_IMAGE);
		PULSAR_CONTAINER.start();
	}

We would still need to find the "magic formula" from inspecting system props to determine if it is M1. However, based on t he info in previous comment it may not be a solid approach w/ sys props as it only reports to the jvm. Let's explore any other means to determine if the current user is on an M1 or not. We could always drop back to the ENVVAR idea as well.

@onobc
Copy link
Collaborator Author

onobc commented May 3, 2023

NOTE: As of 2.11.0 the standard Pulsar image is now able to run on Mac M1.

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

No branches or pull requests

2 participants