hubcio commented on issue #2712: URL: https://github.com/apache/iggy/issues/2712#issuecomment-3877302834
just to make sure we're on the same page - the connectors runtime (binary `iggy-connectors`) is a host process that loads connector plugins (sink/source) as shared libraries (`.so` on Linux, `.dylib` on mac) at startup via dlopen. theplugin `.so` files are separate build artifacts from the runtime binary. the path field in your connector config toml tells the runtime where to find them. if you need some reasoning about why we choose dynamic loading, I gladly invite you to discord so we can talk 😄 (main points are independent release cycles,language-agnostic interface - you can write plugin with any language that allows you to call C code) a few questions about your setup: - how are you running the connectors runtime? built from source, docker image, prebuilt binary? - do you actually have the plugin `.so` files built and on disk? the runtime loads connector plugins as shared libraries via dlopen at startup - they're separate from the runtime binary itself. - what does the path field in your connector config toml look like? absolute or relative? - can you check if the .so file actually exists at that location (or next to the runtime binary)? about point 1: good catch - fixed on branch `iceberg-fix`. we now fall back to modified() when created() isn't supported about point 2: I improved the plugin path resolution.relative paths now search next to the runtime binary, cwd, /usr/lib, /usr/lib64, and /lib. if nothing is found you'll get an error listing all the paths we tried instead of a cryptic dlopen message. See #2713 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
