[ 
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)

Reply via email to