Confluent 4.0启动带Avro支持的Kafka Connect异常求助

这个错误我之前在Confluent 4.0.0的Ubuntu Server环境下碰到过，核心原因是Kafka Connect的类加载器扫描范围错误——它把jar包中的MANIFEST.MF文件当成了class文件来解析（错误日志里的4d616e69对应ASCII的"Mani"，正是MANIFEST.MF的开头字符）。下面是几个经过验证的解决方案：

1. 缩小plugin.path的扫描范围 #

你当前配置的plugin.path大概率指向了整个share/java目录，但这个目录里包含了大量Kafka本身的依赖jar（比如报错里的javassist-3.21.0-GA.jar），这些jar并非Kafka Connect的插件，类加载器扫描时会误处理其中的MANIFEST.MF文件。

修改connect-avro-distributed.properties中的plugin.path，只指向你实际需要的Connect插件目录，比如：

plugin.path=/opt/confluent/confluent-4.0.0/share/java/kafka-connect-avro-converter,/opt/confluent/confluent-4.0.0/share/java/kafka-connect-jdbc,/opt/confluent/confluent-4.0.0/share/java/kafka-connect-file

只包含业务需要的插件目录，避免扫描不必要的jar包。

2. 检查文件权限 #

虽然你复制了正常机器的文件，但Ubuntu Server上可能存在权限问题，导致Connect进程无法正确读取jar包内容。执行以下命令检查权限：

ls -l /opt/confluent/confluent-4.0.0/share/java/

确保运行Connect的用户（比如当前执行命令的用户或confluent系统用户）对所有jar文件拥有读取权限，如果权限不足，用chmod调整：

sudo chmod -R 644 /opt/confluent/confluent-4.0.0/share/java/

3. 升级Confluent版本 #

这个问题是Confluent 4.0.0的一个已知类加载器bug，在后续的4.1.0及以上版本中已经被修复。如果业务允许，建议升级到较新的Confluent OSS版本，彻底解决这个问题。

4. 临时回退到Confluent 3.3.0 #

既然你提到Confluent 3.3.0可以正常运行，在找到合适的升级方案前，可以临时回退到3.3.0版本启动Kafka Connect，保证业务正常运转。

内容的提问来源于stack exchange，提问作者Randomizer