You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jira@kafka.apache.org by "Konstantine Karantasis (Jira)" <ji...@apache.org> on 2021/02/25 08:11:00 UTC
[jira] [Comment Edited] (KAFKA-12308) ConfigDef.parseType deadlock
[ https://issues.apache.org/jira/browse/KAFKA-12308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17290756#comment-17290756 ]
Konstantine Karantasis edited comment on KAFKA-12308 at 2/25/21, 8:10 AM:
--------------------------------------------------------------------------
[~tombentley] I actually think that the initial suggestion in https://issues.apache.org/jira/browse/KAFKA-7421 regarding the removal of the method lock is correct.
The `DelegatingClassLoader` doesn't seem to need to be parallel because it delegates loading to either `PluginClassLoader` instances that are parallel capable or the parent which normally is the system classloader and should also be parallel.
Note, that the loading sequence that you mention above, is inverted on purpose to actually implement classloading isolation. First we attempt loading the class from the "child" `PluginClassLoader` of the designated plugin and if not found then the parent classloader of the `DelegatingClassLoader` is consulted.
I have updated the PR that had added a test for this type of deadlock originally submitted by [~gharris1727] in:
[https://github.com/apache/kafka/pull/8259]
cc [~rhauch]
was (Author: kkonstantine):
[~tombentley] I actually think that the initial suggesting in https://issues.apache.org/jira/browse/KAFKA-7421 regarding the removal of the method lock is correct.
The `DelegatingClassLoader` doesn't seem to need to be parallel because it delegates loading to either `PluginClassLoader` instances that are parallel capable or the parent which normally is the system classloader and should also be parallel.
Note, that the loading sequence that you mention above, is inverted on purpose to actually implement classloading isolation. First we attempt loading the class from the "child" `PluginClassLoader` of the designated plugin and if not found then the parent classloader of the `DelegatingClassLoader` is consulted.
I have updated the PR that had added a test for this type of deadlock originally submitted by [~gharris1727] in:
[https://github.com/apache/kafka/pull/8259]
cc [~rhauch]
> ConfigDef.parseType deadlock
> ----------------------------
>
> Key: KAFKA-12308
> URL: https://issues.apache.org/jira/browse/KAFKA-12308
> Project: Kafka
> Issue Type: Bug
> Components: config, KafkaConnect
> Affects Versions: 2.5.0
> Environment: kafka 2.5.0
> centos7
> java version "1.8.0_231"
> Reporter: cosmozhu
> Priority: Major
> Attachments: deadlock.log
>
>
> hi,
> the problem was found, when I restarted *ConnectDistributed*
> I restart ConnectDistributed in the single node for the test, with not delete connectors.
> sometimes the process stopped when creating connectors.
> I add some logger and found it had a deadlock in `ConfigDef.parseType`.My connectors always have the same transforms. I guess when connector startup (in startAndStopExecutor which default 8 threads) and load the same class file it has something wrong.
> I attached the jstack log file.
> thanks for any help.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)