Return-Path: X-Original-To: apmail-flink-dev-archive@www.apache.org Delivered-To: apmail-flink-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 1EE22187FE for ; Wed, 16 Sep 2015 14:51:46 +0000 (UTC) Received: (qmail 40897 invoked by uid 500); 16 Sep 2015 14:51:11 -0000 Delivered-To: apmail-flink-dev-archive@flink.apache.org Received: (qmail 40838 invoked by uid 500); 16 Sep 2015 14:51:11 -0000 Mailing-List: contact dev-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 dev@flink.apache.org Received: (qmail 40824 invoked by uid 99); 16 Sep 2015 14:51:11 -0000 Received: from Unknown (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 16 Sep 2015 14:51:11 +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 DB5BA1A20D7 for ; Wed, 16 Sep 2015 14:51:10 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 2.879 X-Spam-Level: ** X-Spam-Status: No, score=2.879 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd2-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-us-east.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id CrNASCvYmWbt for ; Wed, 16 Sep 2015 14:51:09 +0000 (UTC) Received: from mail-la0-f47.google.com (mail-la0-f47.google.com [209.85.215.47]) by mx1-us-east.apache.org (ASF Mail Server at mx1-us-east.apache.org) with ESMTPS id 741D542F31 for ; Wed, 16 Sep 2015 14:51:09 +0000 (UTC) Received: by lamp12 with SMTP id p12so129473343lam.0 for ; Wed, 16 Sep 2015 07:51:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=11cAsfw1n8R4xN19NpMxd/WoIQM9sPzYZcmlVrp6TOg=; b=JZclW8bEouu1CelrDQwn0gI6cxKFq02d6iPlH+uK60RPE3vVeCP6c4ERCj77ZJrgn2 NTkM3tkiAtU5FXV197pqcagzKugsCsEGBdwslqS3MGwEFXEsgLbFAwgcD+kGhSTHp47J BCOSW9GxdJwSvnG0J/mmKPd5xykZAW4nGkRCUtL48Exi4lDda6Cj/SBStumhVRoR7HX4 c91+SR2VhN0x+K8pREwTo/8tE3Bd6n2m/0cD1YnTpDgr7f5/Qp2ysbkSqXgA1g8o3GQ9 mrKeWPN5NbgIMc7kq3pkqwivQ28E5L6NH8psrUeA1cgBFRc/crRRgT5XM9+LpYZZcnGh Y79w== X-Received: by 10.112.91.196 with SMTP id cg4mr30019294lbb.10.1442415068347; Wed, 16 Sep 2015 07:51:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.40.140 with HTTP; Wed, 16 Sep 2015 07:50:38 -0700 (PDT) In-Reply-To: References: From: Fabian Hueske Date: Wed, 16 Sep 2015 16:50:38 +0200 Message-ID: Subject: Re: CompactingHashTable question To: "dev@flink.apache.org" Content-Type: multipart/alternative; boundary=001a113494dac484ed051fde6d39 --001a113494dac484ed051fde6d39 Content-Type: text/plain; charset=UTF-8 Hi Vasia, I looked into the code. A serializer should never return null when deserializing. Either it does not detect that something went wrong with the deserialization or it should throw an exception. Regarding the handling of null returns in the Drivers. If there is no entry in the HT for a certain key, the HT will return null which is expected. If a CoGroupWithSolutionSet*Driver receives a null value, it gives an empty iterator to the user function. The JoinWithSolutionSet*Driver calls the join function with a null value. Both behaviors are expected. A join with a solution set is actually an outer join and a join function in such a join needs to be able to handle null values on the solution set side. Cheers, Fabian 2015-09-15 17:41 GMT+02:00 Vasiliki Kalavri : > Hello to my squirrels, > > I ran into an NPE for some iterations code and it looks like what's > described in FLINK-2443 >. > I'm trying to understand the problem and I could really use your help :) > > So far, it seems that the exception is caused by a null value returned by > CompactingHashTable.*getMatchFor*(PT probeSideRecord). > > This method returns null in the following cases: > - when the hash table is "closed" > - when the segment is done > - if the serializer actually returns a null record > > It seems that on the join/cogroup driver side there is no check or special > handling when the build side record is null, i.e. the null record is still > passed to the join function. > Is this correct and if not, what should the driver do in this case? > > Thank you! > > Cheers, > Vasia. > --001a113494dac484ed051fde6d39--