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 38E82200CA5 for ; Sat, 10 Jun 2017 13:11:22 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id 375DD160BDA; Sat, 10 Jun 2017 11:11:22 +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 7DA62160BD7 for ; Sat, 10 Jun 2017 13:11:21 +0200 (CEST) Received: (qmail 41318 invoked by uid 500); 10 Jun 2017 11:11:20 -0000 Mailing-List: contact issues-help@flink.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@flink.apache.org Delivered-To: mailing list issues@flink.apache.org Received: (qmail 41309 invoked by uid 99); 10 Jun 2017 11:11:20 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 10 Jun 2017 11:11:20 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd2-us-west.apache.org (ASF Mail Server at spamd2-us-west.apache.org) with ESMTP id 529AD1A0062 for ; Sat, 10 Jun 2017 11:11:20 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -98.702 X-Spam-Level: X-Spam-Status: No, score=-98.702 tagged_above=-999 required=6.31 tests=[KAM_ASCII_DIVIDERS=0.8, KAM_NUMSUBJECT=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=disabled Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id SEJ6dEq6UFbA for ; Sat, 10 Jun 2017 11:11:19 +0000 (UTC) Received: from mailrelay1-us-west.apache.org (mailrelay1-us-west.apache.org [209.188.14.139]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTP id D39895F253 for ; Sat, 10 Jun 2017 11:11:18 +0000 (UTC) Received: from jira-lw-us.apache.org (unknown [207.244.88.139]) by mailrelay1-us-west.apache.org (ASF Mail Server at mailrelay1-us-west.apache.org) with ESMTP id 55811E00A3 for ; Sat, 10 Jun 2017 11:11:18 +0000 (UTC) Received: from jira-lw-us.apache.org (localhost [127.0.0.1]) by jira-lw-us.apache.org (ASF Mail Server at jira-lw-us.apache.org) with ESMTP id 118E72193D for ; Sat, 10 Jun 2017 11:11:18 +0000 (UTC) Date: Sat, 10 Jun 2017 11:11:18 +0000 (UTC) From: "Tzu-Li (Gordon) Tai (JIRA)" To: issues@flink.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Updated] (FLINK-6883) Serializer for collection of Scala case classes are generated with different anonymous class names in 1.3 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 archived-at: Sat, 10 Jun 2017 11:11:22 -0000 [ https://issues.apache.org/jira/browse/FLINK-6883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tzu-Li (Gordon) Tai updated FLINK-6883: --------------------------------------- Description: In the Scala API, serializers are generated using Scala macros (via the {{org.apache.flink.streaming.api.scala.createTypeInformation(..)}} util). The generated serializers are inner anonymous classes, therefore classnames will differ depending on when / order that the serializers are generated. From 1.1 / 1.2 to Flink 1.3, the generated classnames for a serializer for a collections of case classes (e.g. {{List[SomeUserCaseClass]}}) will be different. In other words, the exact same user code written in the Scala API, compiling it with 1.1 / 1.2 and with 1.3 will result in different classnames. This is problematic for restoring older savepoints that have Scala case class collections in their state, because the old serializer cannot be recovered (due to the generated classname change). For now, I've managed to identify that the root cause for this is that in 1.3 the {{TypeSerializer}} base class additionally extends the {{TypeDeserializer}} interface. Removing this extending resolves the problem. The actual reason for why this affects the generated classname is still being investigated. was: In the Scala API, serializers are generated using Scala macros (via the {{org.apache.flink.streaming.api.scala.createTypeInformation(..)}} util). The generated serializers are inner anonymous classes, therefore classnames will differ depending on when / order that the serializers are generated. From 1.1 / 1.2 to Flink 1.3, the generated classnames for a serializer for a collections of case classes (e.g. {{List[SomeUserCaseClass]}}) will be different. In other words, the exact same user code written in the Scala API, compiling it with 1.1 / 1.2 and with 1.3 will result in different classnames. This is problematic for restoring older savepoints that have Scala case class collections in their state, because the old serializer cannot be recovered (due to the generated classname change). For now, I've managed to identify that the root cause for this is that in 1.3 the {{TypeSerializer}} base class additionally extends the {{TypeDeserializer}} interface. Removing this extending resolves the problem. The actual reason what this affects the generated classname is still being investigated. > Serializer for collection of Scala case classes are generated with different anonymous class names in 1.3 > --------------------------------------------------------------------------------------------------------- > > Key: FLINK-6883 > URL: https://issues.apache.org/jira/browse/FLINK-6883 > Project: Flink > Issue Type: Bug > Components: Scala API, Type Serialization System > Affects Versions: 1.3.0 > Reporter: Tzu-Li (Gordon) Tai > Assignee: Tzu-Li (Gordon) Tai > Priority: Blocker > Labels: flink-rel-1.3.1-blockers > Fix For: 1.3.1 > > > In the Scala API, serializers are generated using Scala macros (via the {{org.apache.flink.streaming.api.scala.createTypeInformation(..)}} util). > The generated serializers are inner anonymous classes, therefore classnames will differ depending on when / order that the serializers are generated. > From 1.1 / 1.2 to Flink 1.3, the generated classnames for a serializer for a collections of case classes (e.g. {{List[SomeUserCaseClass]}}) will be different. In other words, the exact same user code written in the Scala API, compiling it with 1.1 / 1.2 and with 1.3 will result in different classnames. > This is problematic for restoring older savepoints that have Scala case class collections in their state, because the old serializer cannot be recovered (due to the generated classname change). > For now, I've managed to identify that the root cause for this is that in 1.3 the {{TypeSerializer}} base class additionally extends the {{TypeDeserializer}} interface. Removing this extending resolves the problem. The actual reason for why this affects the generated classname is still being investigated. -- This message was sent by Atlassian JIRA (v6.3.15#6346)