Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id F168B200B4A for ; Wed, 20 Jul 2016 17:18:39 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id EF7EF160A64; Wed, 20 Jul 2016 15:18:39 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id EDD27160A5B for ; Wed, 20 Jul 2016 17:18:38 +0200 (CEST) Received: (qmail 83884 invoked by uid 500); 20 Jul 2016 15:18:38 -0000 Mailing-List: contact user-help@flink.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@flink.apache.org Delivered-To: mailing list user@flink.apache.org Received: (qmail 83874 invoked by uid 99); 20 Jul 2016 15:18:38 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 20 Jul 2016 15:18:38 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id 93C85C0B66 for ; Wed, 20 Jul 2016 15:18:37 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.279 X-Spam-Level: * X-Spam-Status: No, score=1.279 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=2, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd4-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=zalando-de.20150623.gappssmtp.com Received: from mx2-lw-us.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id vKBaU_2vcl6P for ; Wed, 20 Jul 2016 15:18:34 +0000 (UTC) Received: from mail-wm0-f43.google.com (mail-wm0-f43.google.com [74.125.82.43]) by mx2-lw-us.apache.org (ASF Mail Server at mx2-lw-us.apache.org) with ESMTPS id B511A6125C for ; Wed, 20 Jul 2016 15:18:33 +0000 (UTC) Received: by mail-wm0-f43.google.com with SMTP id i5so73833573wmg.0 for ; Wed, 20 Jul 2016 08:18:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zalando-de.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=9NYppoC5XD269AOafgnjsGTZkPiV5MZnQmkE5299bNA=; b=1ej6J+CKNgrpF12vwaHeMotJ81nxLhHBVWxVo9Tm/uDh/orbhaFNJEJGwcdUDDk60F BixfwYDkC3wzCzefzF0crIt9H5GHNfUZ6YK/dJZfkrxmH0MAHvu8g1tcq5Yynz/jtF8K ndDpsF+xMM24dm7FagMtoHz0TCX95deCufRFU5s5itDY4tjQ4qkDddecyueyVYYk1/FJ m6w4ofWxeRTgnSpRTIuWyURBv3P2OHnKTZcU+N1cX4YsNOCLlxGKFA1GBki1SUaxLGwo QMBOPLb8k2orV2BZd8Q1RBQssf2CgxL2HfVm31duwBznnUr4Dj0E6Zg0+P66bwJWnurf ZpGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=9NYppoC5XD269AOafgnjsGTZkPiV5MZnQmkE5299bNA=; b=kzW2Lk8kbTA9aRsgXPfwsMzZfm1ksp6sgPittcgWijRxTRi8PdmzssqzODQy0CoveN eXgqDsuyiyqZ0DMk3AOzpbhROfF3DJJMMO6HhbKhRsOG4QlgrxCpyuWr8JFG0EzE4PAB SzE+BawhqScx/ZgdHoEzN6hXyZ+kHyn7vhnKo4eJJCIYudpL4YmNketcq043j0x6typ6 azJaF5mGn9D8QPlsV/P6MehNe8kAMujmimTyquzgjTTBR5IJN1Y3TJMCEKrB/7EB2SPw RbrE4DSSuonrx99PYQE+KG41b+YvRnwRW5SOV6uow4zS60Y1vEyigC08TFyqsd6CPu6s MNqQ== X-Gm-Message-State: ALyK8tJlmesLAJ5sT7YWhxAENgMArvDx438LTPoIlvghINn9Rivrhz919MBSr8sbZqiFd6g+ X-Received: by 10.28.129.137 with SMTP id c131mr11303831wmd.79.1469027911413; Wed, 20 Jul 2016 08:18:31 -0700 (PDT) Received: from [10.169.130.200] ([94.135.236.148]) by smtp.gmail.com with ESMTPSA id jj5sm1763778wjb.40.2016.07.20.08.18.30 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Jul 2016 08:18:30 -0700 (PDT) Subject: Re: Class loading and job versioning To: user@flink.apache.org References: <7269292b-bebe-f026-9406-06f79ee47215@zalando.de> <99f82585-5888-5529-2ac8-a3ea7dca7312@zalando.de> From: Michal Budzyn Message-ID: <6be5c4b1-ad85-9888-e33f-e094a3a136ee@zalando.de> Date: Wed, 20 Jul 2016 17:18:29 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------3B8B6CAF81B9484B96CA7058" archived-at: Wed, 20 Jul 2016 15:18:40 -0000 This is a multi-part message in MIME format. --------------3B8B6CAF81B9484B96CA7058 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi Stephan, IMO the platform needs better jobs isolation. All this shading shouldn't be required at all. Michal On 20.07.2016 16:18, Stephan Ewen wrote: > Hi Michael! > > The only safe way in Java to isolate the user code from the platform > would be to completely run them in different JVMs. > > Other than that, Max's method to ensure the correct instantiation > should work in most cases. > > We also continuously try to have fewer dependencies in Flink, to that > there is less to clash. > > Stephan > > > On Wed, Jul 20, 2016 at 3:53 PM, Maximilian Michels > wrote: > > Sure. No Problem. > > The issue is a bit more involved. You're right, the user classes have > precedence over the Flink classpath. So your classes were probably > loaded fine. However, the user code also calls Flink code which can > use a library version different from the job jar library. And boom, it > crashes because the job jar library has been loaded previously :) > > The only way we could circumvent this problem would be to explicitly > set a different classloader and load Flink internal classes via > reflection. I think the performance penalty for this would be way too > high. > > Best, > Max > > On Wed, Jul 20, 2016 at 2:23 PM, Michal Budzyn > > wrote: > > Thanks for the prompt replay. > > > > You are right. The conflict was between > "com.fasterxml.jackson.core" libs. > > > > I am just wondering. If the the jobs were separted from the > platform, > > > > the jobs libs should have precedence and no versioning problem > should have > > happened. > > > > Regards, > > > > Michal > > > > > > > > On 20.07.2016 14:00, Maximilian Michels wrote: > >> > >> Hi Michal, > >> > >> I couldn't find Joda in flink-dist. Possibly there is some > other clash? > >> > >> There are two potential issues here: > >> > >> 1) Flink shades some libraries (Guava) but not all. If you use a > >> version of a library in your Flink job which doesn't match the > one in > >> flink-dist, you're bound for trouble. > >> > >> 2) Flink separates jobs from each other to avoid potential class > >> version mismatches. Each job has its own classloader. In this > sense, > >> "job versioning" is supported. > >> > >> Cheers, > >> Max > >> > >> On Wed, Jul 20, 2016 at 1:02 PM, Michal Budzyn > >> > wrote: > >>> > >>> Hi all, > >>> We had a class versioning problem within Flink Job. > >>> The job uses Joda 2.6, but the flink-dist 1.0.3 packages 2.5. > >>> The problem was solved by relocating job classes with shade > plug-in. > >>> > >>> Does flink separate jobs from each other to avoid class > conflicts between > >>> them and the platform ? > >>> Is job versioning supported or is shading always required ? > >>> > >>> Regards, > >>> Michal > >>> > > > > --------------3B8B6CAF81B9484B96CA7058 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

Hi Stephan,

IMO the platform needs better jobs isolation. All this shading shouldn't be required at all.

Michal




On 20.07.2016 16:18, Stephan Ewen wrote:
Hi Michael!

The only safe way in Java to isolate the user code from the platform would be to completely run them in different JVMs.

Other than that, Max's method to ensure the correct instantiation should work in most cases.

We also continuously try to have fewer dependencies in Flink, to that there is less to clash.

Stephan


On Wed, Jul 20, 2016 at 3:53 PM, Maximilian Michels <mxm@apache.org> wrote:
Sure. No Problem.

The issue is a bit more involved. You're right, the user classes have
precedence over the Flink classpath. So your classes were probably
loaded fine. However, the user code also calls Flink code which can
use a library version different from the job jar library. And boom, it
crashes because the job jar library has been loaded previously :)

The only way we could circumvent this problem would be to explicitly
set a different classloader and load Flink internal classes via
reflection. I think the performance penalty for this would be way too
high.

Best,
Max

On Wed, Jul 20, 2016 at 2:23 PM, Michal Budzyn
<michal.budzyn.extern@zalando.de> wrote:
> Thanks for the prompt replay.
>
> You are right. The conflict was between "com.fasterxml.jackson.core" libs.
>
> I am just wondering. If the the jobs were separted from the platform,
>
> the jobs libs should have precedence and no versioning problem should have
> happened.
>
> Regards,
>
> Michal
>
>
>
> On 20.07.2016 14:00, Maximilian Michels wrote:
>>
>> Hi Michal,
>>
>> I couldn't find Joda in flink-dist. Possibly there is some other clash?
>>
>> There are two potential issues here:
>>
>> 1) Flink shades some libraries (Guava) but not all. If you use a
>> version of a library in your Flink job which doesn't match the one in
>> flink-dist, you're bound for trouble.
>>
>> 2) Flink separates jobs from each other to avoid potential class
>> version mismatches. Each job has its own classloader. In this sense,
>> "job versioning" is supported.
>>
>> Cheers,
>> Max
>>
>> On Wed, Jul 20, 2016 at 1:02 PM, Michal Budzyn
>> <michal.budzyn.extern@zalando.de> wrote:
>>>
>>> Hi all,
>>> We had a class versioning problem within Flink Job.
>>> The job uses Joda 2.6, but the flink-dist 1.0.3 packages 2.5.
>>> The problem was solved by relocating job classes with shade plug-in.
>>>
>>> Does flink separate jobs from each other to avoid class conflicts between
>>> them and the platform ?
>>> Is job versioning supported or is shading always required ?
>>>
>>> Regards,
>>> Michal
>>>
>


--------------3B8B6CAF81B9484B96CA7058--