You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@flink.apache.org by "Stephan Ewen (JIRA)" <ji...@apache.org> on 2018/11/16 17:35:00 UTC

[jira] [Commented] (FLINK-10904) Expose Classloader before Pipeline execution

    [ https://issues.apache.org/jira/browse/FLINK-10904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16689722#comment-16689722 ] 

Stephan Ewen commented on FLINK-10904:
--------------------------------------

Anywhere in the Flink processes (TaskManager) where any application code is involved, the classloader should be available as the thread context classloader. It should be available there before any execution starts, even when deserializing the code from the RPC payload, it should be already available.

> Expose Classloader before Pipeline execution
> --------------------------------------------
>
>                 Key: FLINK-10904
>                 URL: https://issues.apache.org/jira/browse/FLINK-10904
>             Project: Flink
>          Issue Type: Wish
>            Reporter: Luka Jurukovski
>            Priority: Minor
>
> Not sure if this is something that I just have to deal with. However it would be nice if the classloader can be accessed before the pipeline starts executing. The case for this is that I am loading classes that contain Flink operators. I am running into classdef not found issues because the classloader used by Flink is different then the application program that is being run. Currently what I have been doing as a work around is adding the libs that cause these issues in the /lib directory of the Flink cluster and marking it as provided in the application jar that is uploaded to the Flink cluster. The issues with this are two fold, first it makes deployment more complex, as well as there are cases where Classloading causes exceptions to arise in unusual circumstances. Ie RabbitMQ connector caused issues only when it was auto-recovering the connection, but not during normal ingest. I can elaborate further if needed



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)