Confluent-kafka-dotnet: Runtime error: DLLNotFoundException: kernel32

[edhalsim]

Description

I'm getting the following error when running a sample program on CentOS 7:
Unhandled Exception: System.DllNotFoundException: kernel32
at (wrapper managed-to-native) Confluent.Kafka.Impl.LibRdKafka+WindowsNative:LoadLibraryEx (string,intptr,Confluent.Kafka.Impl.LibRdKafka/WindowsNative/LoadLibraryFlags)
at Confluent.Kafka.Impl.LibRdKafka.Initialize (System.String userSpecifiedPath) [0x000b6] in :0
at Confluent.Kafka.Consumer..ctor (System.Collections.Generic.IEnumerable1[T] config) [0x0000c] in <f8eec87f7e1a4d588a368976ab219188>:0 at Confluent.Kafka.Consumer2[TKey,TValue]..ctor (System.Collections.Generic.IEnumerable1[T] config, Confluent.Kafka.Serialization.IDeserializer1[T] keyDeserializer, Confluent.Kafka.Serialization.IDeserializer`1[T] valueDeserializer) [0x0013f] in :0

This is using the librdkafka.so library I pulled and recompiled on CentOS.

Note that the SimpleProducer and SimpleConsumer apps. work fine when running with "dotnet run". My app. I can't run using "dotnet run" because my app. needs to be installed as a Spark process using Mobius, which requires running via: sparkclr-submit.sh.

Any ideas please let me know. Thanks for your time.

[mhowlett]

You'll need to use the Library.Load method to explicitly set the path to your librdkafka.so binary. We will hopefully have out of the box support for CentOS before too long, this is becoming a common issue.

[edhalsim]

Thanks for your reply. I tried that and I'm having the same issue. I added:
Library.Load("/home//Mobius-master/examples/Streaming/Kafka/bin/Release/librdkafka.so");
Then did a rebuild of the Mobius examples on Linux, but when I run it I get exactly the same error. except now it's coming from Library.Load:
at Confluent.Kafka.Impl.LibRdKafka.Initialize (System.String userSpecifiedPath) [0x000b6] in :0
at Confluent.Kafka.Library.Load (System.String path) [0x00000] in :0

[mhowlett]

did you build librdkafka.so on that machine? it may be missing some dependencies. do you require security features? if not you could try disabling them in your librdkafka build. These are responsible for most problems.

[edhalsim]

Yes I built it on my machine. At this time, no, I do not believe I need any security features. How do I disable those in the build?

[ngeor]

Hi, I have the same troubles when trying to use the NuGet package on a non Windows machine.

I tried the Library.Load suggestion and it doesn't work. Digging into the code of "LibRdKafka.cs", I have some idea on why this does not work. On line 216, you have a conditional compile directive. The NuGet package, I believe, is targeted for .NET 4.5/4.6/4.7, which means that the NuGet package is compiled with that region, which never calls the PosixNative internal class.

So I don't think the Library.Load solution can work, unless I recompile the kafka library from source on the target machine (which I can't do).

Is it perhaps possible to remove the conditional compile?

[mhowlett]

@ngeor - the nuget package targets net45 net46 and netstandard1.3. Library.Load has been tested on windows (.NET Framework/.NET Core), ubuntu, debian8/9 and osx.

[ngeor]

@mhowlett I should clarify that I'm talking about .NET Framework 4.6 on Mac & Linux.

When you're producing the NuGet package, you're compiling it. The code I pointed to includes conditional compilation ( the #if directive ). This means that once you've shipped the NuGet package, the code that doesn't meet the conditional compilation directive is gone. To illustrate my point, here's the decompiled version of the dll bundled with the package:

As you can see, this includes only the Windows specific code (all the Posix if/else is gone). The code will always try to use kernel32, regardless of the platform.

Regarding the testing you mentioned, I believe you're probably testing it by compiling your code on all the platforms you support. This of course works, because you're compiling from source.

On an unrelated note, I tested on .NET Core and there everything works great.

[mhowlett]

ahh yes, we don't consider/support mono - we assume NET45, NET46 => windows. Happy to review a PR to change this.

by testing I mean against .NET Core only + referencing nuget packages.

[ngeor]

Hi @mhowlett ,

I have created a PR here: #418

To test it, I built the package on my Windows laptop using my branch. Then, I copied the DLLs on a Linux computer and I used them with the Simple Kafka Producer example (Ubuntu 16.04.3 LTS, mono 4.2.1)

• When using the original DLLs from NuGet, I get the expected kernel32 error
• When using my branch, I get an error that it can't load the native librdkafka library
• When using my branch with a dllmap file, I am able to run the producer sample

The dllmap file as far as I understand needs to be named Confluent.Kafka.dll.config and it needs this content:

<configuration>
  <dllmap dll="librdkafka" target="absolute path to librdkafka.so" />
</configuration>

The file librdkafka.so is already bundled with the librdkafka NuGet package so that's fine. Probably the same will work on Mac with the dylib file.

The PR has no changes on the .NET Core side of things, only on the .NET Framework side ( where NET45, NET46 or NET47 conditionals are active). The change essentially constitutes in examining the OS and if it's not Windows then it doesn't attempt to call the kernel32 import. If the OS is Windows, everything goes as before. From that point of view, it should be safe to merge the PR, but I don't know how to write a test that proves that a Windows built binary will work on Linux/Mac.

I'd appreciate any feedback you might have on this!

[ngeor]

Good morning @mhowlett ,
do you perhaps have any thoughts on the PR?
Best regards,
Nikolaos

[mhowlett]

sorry @ngeor - it's a little bit down in the queue. e.g. I'm going to get #431 in first. I did take a quick look and saw it's a couple of hundred lines of changes (though they may be simple, I didn't think about it) which meant I postponed looking at it further. Since this is a pretty critical part of the code I need to consider it / test it very carefully.

[ngeor]

Thank you @mhowlett of course it totally makes sense. Just a heads up, the reason so many lines seem to have changed is that I grouped some code into smaller methods. But I totally get that it needs time. Thank you for response and let me know if you have any questions.

[mhowlett]

continued in in #418 (PR for this)