[fix] make the Windows native collector start, and smoke test the packages in CI - #4379
Merged
Conversation
Aias00
approved these changes
Sep 13, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
The windows-amd64 native collector still fails to start after #4375, in two separate places. Linux and macOS are unaffected — same commit, same build args.
NotCompliantMBeanException: com.sun.management.ThreadMXBean ... ServiceConfigurationError: RedisCommonCollectImpl could not be instantiated → NullPointerException at sun.net.dns.ResolverConfigurationImpl.stringToList
Cause 1 — the JMX option does nothing on Windows
#4375 relied on
--enable-monitoring=jmxclient, a no-op there (oracle/graal#9563). Strings in the CI Windows binary vs a macOS build of commit 3089f72:JMXConnectorFactorygetLockedMonitorsFix: register
ThreadInfo,LockInfo,MonitorInfo,StackTraceElement,MemoryUsageandGcInfoinreachability-metadata.json; drop the option.Cause 2 — netty's DNS resolver is unavailable on Windows
DefaultClientResourcesholds netty's DNS address resolver group in a static field that cannot initialize in a native image on Windows (oracle/graal#11280, #4304). Usingbuilder()does not avoid it — the failure is in the class initializer. Every collector is constructed eagerly by the ServiceLoader, so this killed the whole process.Fix: create the resources lazily through a holder class. Redis monitoring from a Windows native collector still will not work (needs a GraalVM fix), but the failure is now scoped to Redis at collect time.
CI smoke test
All four startup bugs found so far shipped as green builds, because the workflow builds the packages but never runs them. Each package is now started before upload and must register its collect strategies and still be alive ten seconds later. Requiring
Started Collectoralone would not be enough — the MXBean crash happened right after that line.Verification
redis, online, heartbeats OKcollector-native-build.ymlon this branch