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

["Randall Hauch (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/KAFKA-9969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Randall Hauch resolved KAFKA-9969.
----------------------------------
      Reviewer: Konstantine Karantasis
    Resolution: Fixed

[~kkonstantine] merged to `trunk` and backported to:
* `2.6` for inclusion in upcoming 2.6.0
* `2.5` for inclusion in upcoming 2.5.1
* `2.4` for inclusion in a future 2.4.2
* `2.3` for inclusion in a future 2.3.2

> 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.5.0, 2.4.1
>            Reporter: Greg Harris
>            Assignee: Greg Harris
>            Priority: Major
>             Fix For: 2.3.2, 2.6.0, 2.4.2, 2.5.1
>
>
> 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)