Hi Ian, I wanted to share a combined progress update on both the ‘asterix-podman’ packaging work and my TeaVM investigation related to ‘AsterixHyracksIntegrationUtil’, and wanted to ask a few questions so I can align the proposal correctly.
Firstly, on ‘asterix-podman’: While testing the image build path under WSL Ubuntu with Podman, I reproduced a real portability issue in the container build. The Containerfile uses the short base image name ‘eclipse-temurin:21-jre-jammy’, and on a clean Podman setup without configured unqualified search registries, the build fails at the ‘FROM’ step. After changing the base image references to fully qualified names (docker.io/library/eclipse-temurin:21-jre-jammy), I verified locally that the image build succeeds. I have requested a JIRA account, but it is still pending review. If you think this issue is worth filing now, would you be willing to create the JIRA so I can open a PR against it and reference the issue properly? Secondly, in the browser/WASM direction: Before choosing a runtime, I compared TeaVM with alternatives such as CheerpJ. My current view is that TeaVM remains the best primary path for the project, primarily because it aligns better with the open implementation direction, while CheerpJ seems more suitable as a comparison/evaluation runtime. After that, I started with small TeaVM probes before touching AsterixDB itself: - Basic threading probes were encouraging. ‘Thread.sleep()’ and ‘join()’ behaved successfully in the TeaVM/browser target. - Basic file I/O probes were also encouraging in isolation. - Raw socket-style behavior failed, which was expected for the browser target. - Reflection initially failed, but I was able to get a targeted reflection probe working by explicitly preserving metadata. Then I moved on to ‘AsterixHyracksIntegrationUtil’ in layers rather than trying to run it all at once. The first direct result was that simply forcing class initialization of the harness failed very early, before any meaningful cluster bootstrap. The failure path first appeared through ‘FileUtil’, so even ‘FileUtil.joinPath(..)’ was enough to trigger the same problem. After that, I tested related pieces separately and saw the same pattern with ‘ConfigManager’ and later ‘CCApplication.’ The common problem was Log4j initialization pulling in Java/JDK classes and methods that TeaVM was not providing in this path. The specific missing pieces included: - java.util.concurrent.locks.ReentrantLock - java.util.concurrent.locks.Lock - java.util.concurrent.locks.ReentrantReadWriteLock - java.util.concurrent.ConcurrentHashMap.newKeySet() - java.lang.System.getenv() - java.lang.Class.getResource(...) - java.lang.ClassLoader.getResources(...) - java.lang.RuntimePermission - java.util.Date.toInstant() To get past that first wall and see what would break next, I used a small local non-operational logger in the TeaVM probe project just for testing. With that local bypass in place, I was able to: - Instantiate the bootstrap application classes (’CCApplication’, ‘NCApplication’, ‘CCNCApplication’) - Create a ‘ConfigManager.’ - And move one layer deeper into the bootstrap/config path. After that, I tested CC-only and NC-only config registration separately. At that point, both paths failed on the next real blockers, which were no longer just logging-related: - java.util.Properties.store(..) - java.net.InetAddress - java.lang.Runtime.maxMemory() So my understanding has changed a bit during testing. At first, I expected the next big problem after the early probes to be mainly related to later socket communication. But from the actual AHIU-related testing, it looks like the truth is that browser/JVM incompatibilities already show up earlier in the bootstrap/config layer itself. Your suggestion to investigate ‘AsterixHyracksIntegrationUtil’ directly was very helpful, because it gave me a concrete path to follow and helped me see where the first real blockers are. Based on what I found, I am currently thinking that ‘AsterixHyracksIntegrationUtil’ can serve as a very strong reference for the startup flow, while the actual browser implementation may need a browser-oriented bootstrap layer around the same ideas, bringing up a controlled single-node runtime and replacing browser-incompatible assumptions step by step. A few things I would really appreciate your guidance on: 1- Does that direction sound reasonable to you? In other words, does it make sense to treat ‘AsterixHyracksIntegrationUtil’ as the guide for the startup flow, while shaping a browser-oriented entry path around it as we hit these blockers? For the first working version, I am leaning toward a very controlled single-node setup with a minimal query entry path rather than trying to preserve the whole current CC/NC communication model immediately. Does that sound like the right way to narrow the scope? 2- As I write the proposal, I want to present the blocker-handling plan in the right way. From your perspective, should I focus that section on browser-specific adaptations for things like logging, configuration, memory defaults, and networking assumptions, or would you rather I frame it around deeper refactoring of the current paths? 3- More broadly, I want to make sure I am describing the implementation target correctly. Right now, I see the project as narrowing the current startup path into something that can realistically run in a browser tab, rather than trying to preserve every current assumption from the normal JVM/server environment. I would really value your view on whether that matches how you see the project. Thank you again for the earlier guidance. Your suggestion to investigate ‘AsterixHyracksIntegrationUtil’ directly was extremely helpful, and it gave me a much clearer picture of where the first real browser/WASM blockers actually are. Best regards, Adan Ali.
