You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@kafka.apache.org by "Randall Hauch (JIRA)" <ji...@apache.org> on 2019/05/15 15:48:00 UTC

[jira] [Created] (KAFKA-8368) Errors when attempting to use connectors that are in multiple Kafka Connect plugins

Randall Hauch created KAFKA-8368:
------------------------------------

             Summary: Errors when attempting to use connectors that are in multiple Kafka Connect plugins
                 Key: KAFKA-8368
                 URL: https://issues.apache.org/jira/browse/KAFKA-8368
             Project: Kafka
          Issue Type: Bug
          Components: KafkaConnect
    Affects Versions: 0.11.0.0
            Reporter: Randall Hauch


This problem was introduced with the classloader isolation in [KIP-146|https://cwiki.apache.org/confluence/display/KAFKA/KIP-146+-+Classloading+Isolation+in+Connect]. It's not normally a problem since a known limitation is that Connect does not support multiple versions of the same connector.

However, this problem can occur even when each connector is installed only once, when one connector plugin is based on and specializes a different connector plugin. This can lead to an ambiguity when instantiating one of the connectors that appears in multiple plugins.

Consider an example where plugin "foo" contains the "com.acme.FooConnector" class, and plugin "bar" contains a "org.other.BarConnector" class that depends on the "com.acme.FooConnector" class and therefore includes the "foo" JARs in the "bar" plugin. In this case, the "com.acme.FooConnector" appears in two plugins, and when a user chooses to run a connector using the "com.acme.FooConnector" class, Connect will choose (depending upon JVM) either the "foo" plugin or the "bar" plugin. In some cases, this might be the wrong one (e.g., the "bar" plugin contains an older version of "foo".

Arguably this is another manifestation of the version problem, but in this case the "bar" plugin does not intend to expose the "com.acme.FooConnector" -- and if it does then the "foo" plugin is installed and should take precedence.

One potential solution is to hide any concrete connector class in a plugin when that class a) is subclassed in that same plugin, and b) not subclassed in a different plugin.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)