We’re trying to deploy the multi-version client in our Clojure app so we can upgrade our FDB 7.1 cluster to 7.3 with minimal downtime. Because the app is Clojure, and thus runs on the JVM and has full JVM interop, we’re using the Java bindings with our own shim to make interacting with it ‘Clojure-ish’.
Our CI pipeline (Linux, x86_64) is throwing a load of errors when a 7.3 client with the external lib for 7.1 loaded tries to talk to a 7.1 server. I know basic functionality works (I have SSHed in to the pipeline runner and executed a simple get), so I’m pretty sure this is something weird our app is doing that I need to debug.
Trying to debug this on the CI machine without my IDE etc is a massive pain in the ass, so I’m trying to replicate the failure on my local dev machine (MacOS, arm64), but I am completely failing to get the client to talk directly to a 7.1 local server there.
The story so far:
7.3 client with 7.3 server works fine.
7.3 client with FDB.options().setDisableLocalClient() and no external libs loaded doesn’t work (as expected).
7.3 client with FDB.options().setDisableLocalClient()andFDB.options().setExternalClientLibrary("/path/to/external/7.3/libfdb_c.so") against a 7.3 server does work, so I’ve proved that loading external client libs ‘in general’ is working.
7.3 client with FDB.options().setExternalClientLibrary("/path/to/external/7.1/libfdb_c.so") against a 7.1 server just times out when I try to make a request.
The same pattern works fine on the CI machine, so this would seem to be something specific to MacOS (or arm64). What else do I need to do to get the 7.3 client on MacOS to talk to a 7.1 server successfully?
Based on our experimentation, I was under the impression that there was no 7.1 libfdb_c.so that would work on an MacOS arm64, so are you using the x86_64 version of libfdb_c.so or something?
Our environment is a bit different in that we are running our Java application in an ubuntu docker container (on MacOS arm64), so maybe this is different than your environment if you’re running directly on the Mac.
I was also puzzled about version compatibility, and I thought that your client language bindings (i.e. fdb-java) couldn’t be newer than the client library. In other words, I would’ve thought that the 7.3 client couldn’t use the 7.1 libfdb_c.so, but the 7.1 client could use the 7.3 libfdb_c.so. Though this was only based on my testing using Python, not Java.
I didn’t. But you make a good point about 7.1 arm64. I know that when we first started using FDB we were using the x86_64 client on MacOS arm64, and had to use releases which didn’t have the avx extensions enabled because Rosetta/Qemu (for running in a container) didn’t support those, so I may well have had the extra issue (that didn’t occur to me until you mentioned it) that my 2 libraries were for different platforms…
Then again, our CTO did manage to get FDB to compile on MacOS arm64, so maybe we were using the version from that… It was long enough ago that I’ve forgotten.
I got to the bottom of our CI failures by debugging it on CI in the end, so we managed to do the 7.1->7.3 upgrade without issue in our deployed environments, then we switched to 7.3 locally using arm64 native and a lot of the additional complexity went away.