ibm-messaging
ARM image in IBM Container Registry
Is there any chance the IBM Container Registry to host also arm64 variant ? It will make the life of M1-3 CPU owner much easier ? :-)
There is always a chance :) It's not something we're actively working on at the moment though. One bit of good news (as a Applie silicon Mac user myself), is that Podman 5.x fixes the bugs with emulation, which means you can run the amd64 image on arm64 now. This works for me on Podman 5.1.1:
podman run --platform=linux/amd64 --rm -ti -e LICENSE=accept icr.io/ibm-messaging/mq
We use it in our component tests (Testcontainers with Docker), would be nice to have a native image for arm64 in addition.
Actually I was going to write that. We also use it for testcontainers tests, and I've prepared a docker image with all the queues and settings in order to be easy to write integration tests, but I cannot automate the multiplatform building of a new version, because I'm forced to do two images, one for arm and one for amd.
Also in the tests we are doing some weird stuff for the image name -> (System.getProperty("os.arch").equals("aarch64") ? "9.4.0.0-arm64" : "latest"). We have like 80/20 arm vs amd dev machines.
We are also using docker-compose in order to have local setup for local development and because of the two images we cannot use SB support for docker compose, which greatly simplifies the local setup and the development cycle.
Note that only MQ Advanced for Developers is available on arm64. Please be aware that there are restrictions on the use of MQ Advanced for Developers, such as it only being for a single user on a machine "accessible and used by no more than one developer": https://www.ibm.com/support/customer/csol/terms/?id=L-CLXQ-ADXTK3&lc=en. I believe you can purchase cheaper non-production licenses for test pipelines. I'm not implying anything here, just FYI.
Thanks for feedback, which is always useful to hear, because unless we hear about people wanting this, it is never likely to bubble up the list of priorities.
Can MQ Advanced for Developers support Kunpeng 920 CPU which is Arm-based server CPU. Architecture is ARMv8.2
https://www.hisilicon.com/en/products/Kunpeng/Huawei-Kunpeng/Huawei-Kunpeng-920
There is no formal support for arm64 at all. There is a build of MQ Advanced for Developers available, but it only receives limited testing. I believe it might target ARM v8, and should work on ARM v9, but there are no guarantees.
Would love to see MQ for Developers image in MQ container registry for amd/arm. Any plans for that in future release ?
There is always a chance :) It's not something we're actively working on at the moment though. One bit of good news (as a Applie silicon Mac user myself), is that Podman 5.x fixes the bugs with emulation, which means you can run the amd64 image on arm64 now. This works for me on Podman 5.1.1:
podman run --platform=linux/amd64 --rm -ti -e LICENSE=accept icr.io/ibm-messaging/mq
I have just tried this - Container runs and I am able to login as well.
But the default queue manager does not seem it start up and fails with an SSL error .
2025-04-23T15:49:21.982Z CWWKO0801E: The SSL connection cannot be initialized from the 10.88.0.33 host and 9,443 port on the remote client to the 192.168.127.1 host and 39,367 port on the local server. Exception: javax.net.ssl.SSLException: The WebSphere server received an unencrypted inbound communication on a secure connection. This does not indicate a problem with the WebSphere server. To resolve the issue, configure the client to use SSL or to connect to a port on the WebSphere server that does not require SSL.\n at com.ibm.ws.channel.ssl.internal.SSLHandshakeErrorTracker.noteHandshakeError(SSLHandshakeErrorTracker.java:88)\n at com.ibm.ws.channel.ssl.internal.SSLConnectionLink.readyInbound(SSLConnectionLink.java:628)\n at com.ibm.ws.channel.ssl.internal.SSLConnectionLink.ready(SSLConnectionLink.java:348)\n at com.ibm.ws.tcpchannel.internal.NewConnectionInitialReadCallback.sendToDiscriminators(NewConnectionInitialReadCallback.java:169)\n at com.ibm.ws.tcpchannel.internal.NewConnectionInitialReadCallback.complete(NewConnectionInitialReadCallback.java:77)\n at com.ibm.ws.tcpchannel.internal.WorkQueueManager.requestComplete(WorkQueueManager.java:516)\n at com.ibm.ws.tcpchannel.internal.WorkQueueManager.attemptIO(WorkQueueManager.java:586)\n at com.ibm.ws.tcpchannel.internal.WorkQueueManager.workerRun(WorkQueueManager.java:970)\n at com.ibm.ws.tcpchannel.internal.WorkQueueManager$Worker.run(WorkQueueManager.java:1059)\n at com.ibm.ws.threading.internal.ExecutorServiceImpl$RunnableWrapper.run(ExecutorServiceImpl.java:298)\n at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1160)\n at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)\n at java.lang.Thread.run(Thread.java:825)\n
Is this something that you have encountered ?
Using a mac M1 here :(
