From dev-return-27817-archive-asf-public=cust-asf.ponee.io@geode.apache.org Thu Jan 25 21:44:41 2018 Return-Path: X-Original-To: archive-asf-public@eu.ponee.io Delivered-To: archive-asf-public@eu.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by mx-eu-01.ponee.io (Postfix) with ESMTP id 94948180651 for ; Thu, 25 Jan 2018 21:44:41 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id 84E2C160C3D; Thu, 25 Jan 2018 20:44:41 +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 A36E3160C17 for ; Thu, 25 Jan 2018 21:44:40 +0100 (CET) Received: (qmail 10855 invoked by uid 500); 25 Jan 2018 20:44:39 -0000 Mailing-List: contact dev-help@geode.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@geode.apache.org Delivered-To: mailing list dev@geode.apache.org Received: (qmail 10837 invoked by uid 99); 25 Jan 2018 20:44:38 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 25 Jan 2018 20:44:38 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id 50C41C074F for ; Thu, 25 Jan 2018 20:44:38 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -0.02 X-Spam-Level: X-Spam-Status: No, score=-0.02 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=disabled Authentication-Results: spamd1-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=pivotal-io.20150623.gappssmtp.com Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id zjNsIZeF3Xyx for ; Thu, 25 Jan 2018 20:44:36 +0000 (UTC) Received: from mail-qt0-f170.google.com (mail-qt0-f170.google.com [209.85.216.170]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTPS id BECC05F2C3 for ; Thu, 25 Jan 2018 20:44:35 +0000 (UTC) Received: by mail-qt0-f170.google.com with SMTP id a27so22687690qtd.1 for ; Thu, 25 Jan 2018 12:44:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pivotal-io.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=hCDNYBXz+9mwrtcOlLA/GzrXb+VHJMe912DlWYP+V04=; b=pNLCLZIS6lBlxaWPZnuOcErLwJQLJ6WbQHFnrwuVw8xTK56Ys8TdCDcGK/W7mWhX5v xlqF4x4wU8wdeOqBFNaCXrr+kbS2HQcktilt6iAKgE7Syc1NbSsojSPkXdKMOaKfijS5 qnJgzG4xyMGa5biqm2uXDWDN/5XqzHBeU9xURCvjYLdkgmVdJh9OfcWE1GQ2qig1zwBC 93i+YFs+qaRT8LtUnC33Tbx1l7rwwTuWTaJxJal+2zvFpMo198RaoVy7nFDP+hjiiTXW etqrRcIkByEshly9pzPkKPlaO+e+8F3vya+7pY7L9JJVyptJHFCWRFL89NoAQyLLy7MW R3Mw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=hCDNYBXz+9mwrtcOlLA/GzrXb+VHJMe912DlWYP+V04=; b=DYZmHX3YiOWYQHwPY0ELL45plv/O1/EjNPZ1I9OO/QpKPzZzjsTxQtz/nDtMIfpRpK +k2M78MPBVUsqUc1ZwV/yuywrQ6YMF9WicsNTmrYmtYmXC7jDFGTrqkaR0up/xK+7GEc 3XZmVebm7HFBmHOQ3RuAR2AXHe/t9xCcCjeNletj0Zd8BLOujjYpZRTPxcl7YbTZ/sly LO2C+UVmKHn78VhcjTkBYk7OYQoQIulGiVcapV+XyBUo7pbd2upc47VkgydcIZMvauhu zXSYanSQ+zf5odWMlXf5TFxg3Q7/9zkozeMIuG3LMQeo9Jb70MqWo6OqlsUhGHmVs3xz mbMw== X-Gm-Message-State: AKwxytfxRwRJpCIA4wap9pDzv6BaythLG9ewAg+SAl4RaRoVVekqcV38 bLWRlilXy9jcIk4XXXbYyEXo9w== X-Google-Smtp-Source: AH8x22542fFuVyNe2DGsB975f6RiTje+//5jy1rfyet99E0xKorfzQYFUVIcpCILII75CayqioDo1Q== X-Received: by 10.200.64.219 with SMTP id f27mr17723383qtm.227.1516913075296; Thu, 25 Jan 2018 12:44:35 -0800 (PST) Received: from [10.118.20.100] (50-203-225-134-static.hfc.comcastbusiness.net. [50.203.225.134]) by smtp.gmail.com with ESMTPSA id n25sm4458038qtf.58.2018.01.25.12.44.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Jan 2018 12:44:34 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: Proposal: GEODE-4367 - Return PDXInstance when Domain Object can't be found From: Jacob Barrett X-Mailer: iPhone Mail (15C202) In-Reply-To: Date: Thu, 25 Jan 2018 12:44:32 -0800 Cc: "Schuchardt, Bruce" Content-Transfer-Encoding: quoted-printable Message-Id: <8870A9ED-410E-472E-92D9-4954B0589341@pivotal.io> References: <2b69a46f-e852-af18-4fbb-5d10dfd0abd5@apache.org> To: dev@geode.apache.org > On Jan 25, 2018, at 12:06 PM, Anilkumar Gingade wrot= e: >=20 > Jake, >=20 > Interesting...Its the argument passed to function that is in deserialized > form, right? Yes, if pdx read serialized is false (default) the argument is deserialized t= o domain object or fails if no domain object found. If read serialized is tr= ue then all arguments that are PDX serialized and passed in as PdxInstance. S= ett my this flag breaks all previous deployed functions that expected domain= objects in the argument. -Jake >=20 > -Anil. >=20 >=20 >=20 >=20 >=20 >=20 >> On Thu, Jan 25, 2018 at 10:12 AM, Jacob Barrett wro= te: >>=20 >> Anil, this wouldn't fix a function execution where a parameter sent to th= e >> function is a PDX serialized object. The function would be invoked on the= >> server with the current global setting and file to deserialize the PDX to= >> domain object. This is why the ask is for it to fall back to PdxInstance i= f >> the domain object is not deployed. >>=20 >> -Jake >>=20 >> On Thu, Jan 25, 2018 at 9:56 AM Anilkumar Gingade >> wrote: >>=20 >>> Internally, there is an option to override read-serialized flag (to >> true); >>> the query engine and other components uses this to keep the data in >>> serialized form and work with PdxInstance... >>>=20 >>> public static void setPdxReadSerialized(Cache cache, boolean >>> readSerialized); >>>=20 >>> We had discussed, making this as a public api...so that any thread that >> can >>> work on PdxInstance can take advantage of it... >>>=20 >>> -Anil. >>>=20 >>>=20 >>> On Thu, Jan 25, 2018 at 9:42 AM, Jacob Barrett >>> wrote: >>>=20 >>>> Bruce, the flag only applies to values serialized with PDX, >>>> DataSerializable objects are not effected by this property. >>>>=20 >>>> I think there is some real value here as a stop gap until we have a >>> better >>>> solution in Geode 2 where the user can have a per request context that >>>> specifies what return type they would like. Consider the user that has >> an >>>> existing application that uses domain objects but wants to deploy >> another >>>> application that doesn't to the same Geode cluster. The only option is >> to >>>> either have all PDX deserialize to domain objects or all returned as >>>> PdxInstance. One of the two applications will not work without >>>> modification. Changing the behavior described by Addison splits the >>>> difference. If the application is, like it is by default, configure to >>>> deserialize PDX to the domain object but the domain object is not >>> deployed >>>> it will now give back the PDX instance rather than failing. >>>>=20 >>>> An explicit use case is user that has both a Java and .NET application.= >>> The >>>> .NET application does not have any Java domain objects to deploy to the= >>>> server but does want to query or run server side functions. The Java >>>> application has deployed the domain objects to the server and >> distributed >>>> functions are written expecting those domain objects on the server. The= >>>> user would have to create Java domain objects for the .NET application >> or >>>> modify their Java application to expect PdxInstance. >>>>=20 >>>>=20 >>>> -Jake >>>>=20 >>>>=20 >>>> On Thu, Jan 25, 2018 at 7:38 AM Bruce Schuchardt < >> bschuchardt@apache.org >>>>=20 >>>> wrote: >>>>=20 >>>>> +1 >>>>>=20 >>>>> I've found the current read-serialized property to be pretty useless. >>>>>=20 >>>>> Having said that, what if the value isn't actually in serialized form >>> in >>>>> the local cache? Is Geode supposed to serialize it & return it? >> What >>>>> if it isn't PDX-serialized? Do we return a byte array? >>>>>=20 >>>>>=20 >>>>>> On 1/24/18 12:21 PM, Dan Smith wrote: >>>>>> Is this really just a workaround for the fact that the >>> read-serialized >>>>> flag >>>>>> applies to the whole cache? I can see that if you have mix of >> regions >>>>> with >>>>>> and without domain classes on the server you might want this >> feature. >>>> Can >>>>>> you provide some more background on your use case? >>>>>>=20 >>>>>> IMO we should get rid of read-serialized in favor of APIs that let >>> the >>>>> user >>>>>> decide whether they get a domain class or a PdxInstance. >>>>>>=20 >>>>>> -Dan >>>>>>=20 >>>>>> On Wed, Jan 24, 2018 at 9:58 AM, Galen O'Sullivan < >>>> gosullivan@pivotal.io >>>>>>=20 >>>>>> wrote: >>>>>>=20 >>>>>>> Hi Addison, >>>>>>>=20 >>>>>>> What kind of setup do you have that is causing you to have PDX >>>>> serialized >>>>>>> objects that cannot be deserialized? Do you have classes that are >>>>> present >>>>>>> on some servers but not others? >>>>>>>=20 >>>>>>> This change would break the contract of region.get() , which is >> that >>>> it >>>>>>> returns a value of a type that can be put into the region. >>>>>>>=20 >>>>>>> Returning something that isn't what the user is expecting to be in >>> the >>>>>>> region would require users to check for PdxInstances every time >> they >>>>> get a >>>>>>> value -- even though the type annotations say that you can't get a >>>>>>> PdxInstance back (except for Region ). >>>>>>>=20 >>>>>>> I think it would be better to have a second API that allows users >> to >>>> get >>>>>>> and put PdxInstance objects in regions. That way, if they want to >>>> handle >>>>>>> the exceptional case where they have a serialized object that >> can't >>> be >>>>>>> deserialized, they can catch the ClassNotFound exception and get >> the >>>>>>> underlying PdxInstance. >>>>>>>=20 >>>>>>> I do think that the possibility of a ClassNotFoundException should >>> be >>>>>>> documented in the Region API. >>>>>>>=20 >>>>>>> Cheers, >>>>>>> Galen >>>>>>>=20 >>>>>>> On Tue, Jan 23, 2018 at 2:56 PM, Addison Huddy >>=20 >>>>> wrote: >>>>>>>=20 >>>>>>>> Hi Geode Devs, >>>>>>>>=20 >>>>>>>> I'm proposing the following change to how we handle >> deserialization >>>>> when >>>>>>>> Domain Objects can't be found and pdx-serialize=3Dfalse. >>>>>>>>=20 >>>>>>>> https://issues.apache.org/jira/browse/GEODE-4367 >>>>>>>>=20 >>>>>>>> Looking forward to the discussion. >>>>>>>>=20 >>>>>>>> \ah >>>>>>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>>=20 >>=20