de.flapdoodle.embed.mongo: Unable to run Embedded MongoDB on Macbook Pro with M1 CPU (ARM architecture)

As title says - it looks similiar to issue #336.

Caused by: org.springframework.beans.BeanInstantiationException: Failed to instantiate [de.flapdoodle.embed.mongo.MongodExecutable]: Factory method 'embeddedMongoServer' threw exception; nested exception is java.lang.IllegalArgumentException: this version does not support 32Bit: Version{3.5.5}:OS_X:B32
	at org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:185)
	at org.springframework.beans.factory.support.ConstructorResolver.instantiate(ConstructorResolver.java:652)
	... 82 more
Caused by: java.lang.IllegalArgumentException: this version does not support 32Bit: Version{3.5.5}:OS_X:B32
	at de.flapdoodle.embed.mongo.Paths.getBitSize(Paths.java:157)
	at de.flapdoodle.embed.mongo.Paths.getPath(Paths.java:97)
	at de.flapdoodle.embed.process.store.LocalArtifactStore.getArtifact(LocalArtifactStore.java:71)
	at de.flapdoodle.embed.process.store.LocalArtifactStore.checkArtifact(LocalArtifactStore.java:38)
	at de.flapdoodle.embed.process.store.ArtifactStore.checkDistribution(ArtifactStore.java:65)
	at de.flapdoodle.embed.process.store.ExtractedArtifactStore.checkDistribution(ExtractedArtifactStore.java:60)
	at de.flapdoodle.embed.process.runtime.Starter.prepare(Starter.java:52)
	at de.flapdoodle.embed.process.runtime.Starter.prepare(Starter.java:45)
	at org.springframework.boot.autoconfigure.mongo.embedded.EmbeddedMongoAutoConfiguration.embeddedMongoServer(EmbeddedMongoAutoConfiguration.java:113)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:566)
	at org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:154)
	... 83 more

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Reactions: 11
  • Comments: 38 (19 by maintainers)

Commits related to this issue

Most upvoted comments

A dirty workaround for local development (don’t use it in prod environment) on your M1 mac you can add the following in the static block of your @SpringBootApplication static { System.setProperty("os.arch", "i686_64"); }

@MatthewRyanRead hmm… seems a little bit more complicated: https://stackoverflow.com/questions/65259300/detect-apple-silicon-from-command-line … i must think about this a little bit.

@michaelmosmann yes, I believe the problem is really 2 fold.

  1. flapdoodle doesn’t recognize the architecture for a M1 Mac (linux/arm64/v8).
  2. Mongo doesn’t provide a “Mac” distribution for linux/arm64/v8.

So really, flapdoodle seems to fall back to the nearest cousin ARM_64/x86_64 Ubuntu.

But since this isn’t the native platform for an M1 Mac, Rosetta 2 attempts to emulate it. And the flapdoodle launcher has apparently found one of the cracks in the emulation, and cannot find /lib64/ld-linux-x86-64.so.2.

So as I mention in this related issue, we really need Mongo to support the linux/arm64/v8 distribution and then for flapdoodle to recognize and use it.

It is weird that native Groovy reports x86_64 while native Java aarch64. I’d expect both to be aarch64

@jgriff … maybe we are looking at the wrong direction … the mongo version 3.4.23 is very old… so i think the case is just the other way… do you know if a process started in native mode can start an other process in emulation mode? So that the right x86-mongodb binary may work?

@MatthewRyanRead is correct:

Groovy must be running on a different Java VM.

My JAVA_HOME wasn’t explicitly set, so Groovy defaulted to my system JVM which was 15.

I use jenv and currently have 17 set globally. But jenv doesn’t export JAVA_HOME by default.

So I just enabled the export plugin to export JAVA_HOME,

❯ jenv enable-plugin export

and now Groovy reports the expected aarch64.

❯ echo $JAVA_HOME
/Users/griff/.jenv/versions/17
❯ groovy -version
Groovy Version: 4.0.0 JVM: 17.0.1 Vendor: Oracle Corporation OS: Mac OS X
❯ groovy -e "println System.properties['os.name']; println System.properties['os.arch']"
Mac OS X
aarch64

But it’s at least worth noting/discovering that older JVMs don’t recognize aarch64.