You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jira@kafka.apache.org by "Greg Harris (Jira)" <ji...@apache.org> on 2020/05/07 19:51:00 UTC

[jira] [Created] (KAFKA-9969) ConnectorClientConfigRequest is loaded in isolation and throws LinkageError

Greg Harris created KAFKA-9969:
----------------------------------

             Summary: ConnectorClientConfigRequest is loaded in isolation and throws LinkageError
                 Key: KAFKA-9969
                 URL: https://issues.apache.org/jira/browse/KAFKA-9969
             Project: Kafka
          Issue Type: Bug
          Components: KafkaConnect
    Affects Versions: 2.4.1, 2.5.0
            Reporter: Greg Harris
            Assignee: Greg Harris


ConnectorClientConfigRequest (added by [KIP-458|https://cwiki.apache.org/confluence/display/KAFKA/KIP-458%3A+Connector+Client+Config+Override+Policy]) is a class in connect-api, and should always be loaded by the system classloader. If a plugin packages the connect-api jar, the REST API may fail with the following stacktrace:

{noformat}
java.lang.LinkageError: loader constraint violation: loader (instance of sun/misc/Launcher$AppClassLoader) previously initiated loading for a different type with name "org/apache/kafka/connect/connector/policy/ConnectorClientConfigRequest" at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:763) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) at java.net.URLClassLoader.defineClass(URLClassLoader.java:468) at java.net.URLClassLoader.access$100(URLClassLoader.java:74) at java.net.URLClassLoader$1.run(URLClassLoader.java:369) at java.net.URLClassLoader$1.run(URLClassLoader.java:363) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:362) at java.lang.ClassLoader.loadClass(ClassLoader.java:424) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349) at java.lang.ClassLoader.loadClass(ClassLoader.java:357) at org.apache.kafka.connect.runtime.AbstractHerder.validateClientOverrides(AbstractHerder.java:416) at org.apache.kafka.connect.runtime.AbstractHerder.validateConnectorConfig(AbstractHerder.java:342) at org.apache.kafka.connect.runtime.distributed.DistributedHerder$6.call(DistributedHerder.java:745) at org.apache.kafka.connect.runtime.distributed.DistributedHerder$6.call(DistributedHerder.java:742) at org.apache.kafka.connect.runtime.distributed.DistributedHerder.tick(DistributedHerder.java:342) at org.apache.kafka.connect.runtime.distributed.DistributedHerder.run(DistributedHerder.java:282) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) ... 1 more
{noformat}

It appears that the other class in org.apache.kafka.connect.connector.policy, ConnectorClientConfigOverridePolicy had a similar issue in KAFKA-8415, and received a fix.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)