From dev-return-28599-apmail-geode-dev-archive=geode.apache.org@geode.apache.org Wed Apr 25 22:41:36 2018 Return-Path: X-Original-To: apmail-geode-dev-archive@minotaur.apache.org Delivered-To: apmail-geode-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 7F1A218061 for ; Wed, 25 Apr 2018 22:41:36 +0000 (UTC) Received: (qmail 5137 invoked by uid 500); 25 Apr 2018 22:41:36 -0000 Delivered-To: apmail-geode-dev-archive@geode.apache.org Received: (qmail 5088 invoked by uid 500); 25 Apr 2018 22:41:36 -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 5077 invoked by uid 99); 25 Apr 2018 22:41:35 -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; Wed, 25 Apr 2018 22:41:35 +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 1ABB61A2572 for ; Wed, 25 Apr 2018 22:41:35 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.299 X-Spam-Level: * X-Spam-Status: No, score=1.299 tagged_above=-999 required=6.31 tests=[HTML_MESSAGE=2, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 eoLMzqnLany0 for ; Wed, 25 Apr 2018 22:41:30 +0000 (UTC) Received: from mx0b-00296801.pphosted.com (mx0b-00296801.pphosted.com [148.163.153.148]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTPS id 9C95E5F67B for ; Wed, 25 Apr 2018 22:41:30 +0000 (UTC) Received: from pps.filterd (m0114586.ppops.net [127.0.0.1]) by mx0b-00296801.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w3PMfUOC002711 for ; Wed, 25 Apr 2018 22:41:30 GMT Received: from mail-lf0-f69.google.com (mail-lf0-f69.google.com [209.85.215.69]) by mx0b-00296801.pphosted.com with ESMTP id 2hj07v1nj0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Wed, 25 Apr 2018 22:41:29 +0000 Received: by mail-lf0-f69.google.com with SMTP id f74-v6so5952378lff.7 for ; Wed, 25 Apr 2018 15:41:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=F3njeTRbtHUQ8OrNPZ/GLrpLojNAgv1wwsL3QGbID8U=; b=ockYQu5FMoIe1zEevxEy+yMID4CwkITVFlNMYUquQEiggH7Y31ld73unDoonX4Spqi cHqA2/54jmyTC+lZ/F0Mep5iowY8z1oV91LejMEU+D8N3qKb8hhrLeXVfJjoFzaz1Iyv a8Ps5bbrxOnEISXFbQlj+G2G1ZFuL16tqepTacGxfLmAqxD0rH8QpaOLiQgRTJ7islVz WQNnQuWGv+vkg+pt39qsA6JqDTczkUzu+nldu20qRQOQDL9/1vkb0U/MjwYbIpCf8ZtC tJeQ2JaHGgoF87yZvCcO7Q5AfPviKEdeI5JpwH/DVHr73G+4vUrKJCDQ6iYkPH8oVojP OqVg== X-Gm-Message-State: ALQs6tBVCd0RYoEIJK4MHv2piC4GyfdT5ZAL45UKbb1sZXbFjN+0i/nq yUJF+GG5KwgdF3hnwiygMXV88fYvuBsUtXqAp3pY4Qej0RVKg/WApuPMyXBTKnBVNB05Nt8hB5a cU+/7Sn18rrkQmY6PzDzM+9WM3uYZdqzuhKE42/RRlxg3tlKdH14XLNQ= X-Received: by 10.46.146.24 with SMTP id k24mr2761495ljg.70.1524696087653; Wed, 25 Apr 2018 15:41:27 -0700 (PDT) X-Google-Smtp-Source: AB8JxZpczjaFgvugio/Qy2fxAh0UXr/bV9qlvSM3SlE+tYtQDexEul704MuOZMGRNMcL4R9hO83XT9E91xKDRTnyJ6o= X-Received: by 10.46.146.24 with SMTP id k24mr2761487ljg.70.1524696087280; Wed, 25 Apr 2018 15:41:27 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:6b09:0:0:0:0:0 with HTTP; Wed, 25 Apr 2018 15:41:26 -0700 (PDT) In-Reply-To: References: From: Patrick Rhomberg Date: Wed, 25 Apr 2018 15:41:26 -0700 Message-ID: Subject: Re: [Discuss] Scope of the CacheElement interface with the respect to the public cluster configuration API To: dev@geode.apache.org Content-Type: multipart/alternative; boundary="089e0823bb34ac57c3056ab3f8c7" X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-04-25_07:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=2 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804250208 X-Proofpoint-Quarantined: 1 --089e0823bb34ac57c3056ab3f8c7 Content-Type: text/plain; charset="UTF-8" Sorry, I forgot to step away from the In The Weeds where I am. o.a.g.cache.configuration.CacheElement is the experimental interface meant to identify an extension's configuration classes for consumption with the new cluster configuration interface. Extension developers can then use the configuration service to disseminate these configuration objects via member groups, consistent with other configuration elements (e.g., indices and gateways). See [1] for the API's proposal. We also have been using this interface internally on some of our own configuration objects, for instance the JDBC's ConnectorService. This allowed us to use some utilities we had made for the easy retrieval of the configuration objects. The lack of documentation on this interface is my core concern. The initial intent was to label those extension's configuration classes, but beyond that, its use is ambiguous. Even within that purview, it's not clear whether an inner class should be required to implement CacheElement. Jinmei and I had a thread recently on a pull request of hers [2] suggesting perhaps "anything you want to be searchable in the config" should have the interface applied to it. That remains more subjective than I'd personally like, but it would at least be documentable. So to return to my initial concerns: our current use of the interface is inconsistent, and with it being an external API, we should properly define the interface's scope for both external and internal use. I propose four possible scopes in the initial message. @Udo, I haven't added a section on the linked proposal, but the page could do with a larger update in any case. I'll start that straight away. [1] Public API for Cluster Configuration Proposal: https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=75975896 [2] PR #1853: https://github.com/apache/geode/pull/1853 On Wed, Apr 25, 2018 at 12:56 PM, Galen O'Sullivan wrote: > It looks like there are two classes called CacheElement in the codebase; > am I correct in thinking that you're referring to > org.apache.geode.cache.configuration.CacheElement? > > This class doesn't have a Javadoc, so it's a little hard as an outsider to > understand exactly what it is or how it's used. Can you explain the basics > of how it's used? > > Thanks, > > Galen > > > > On 4/19/18 5:03 PM, Patrick Rhomberg wrote: > >> Hello all! >> >> We introduced the CacheElement interface as part of our experimental >> API >> to update the cluster configuration. I'd like to solidify and document >> our >> intent for the interface and the extent to which it is expected to apply. >> In its current form, the CacheElement interface extends Serlializable >> and >> Identifiable. Serialization is required for communication between >> members, and Identifiable is useful during lookup, modification, and >> removal of an existing configuration object. >> At our current iteration, it is not entirely clear which of our own >> configuration objects should or should not implement CacheElement. I >> think >> one of following interpretations may be best, but don't know which would >> be >> most natural. And, of course, if you have another that I've overlooked, >> I'd love to hear it. >> >> Classes that implement CacheElement are... >> >> A) ... only custom configuration elements provided by extension >> developers. This declaration will appear at a top-level class declaration >> that is directly consumed by the CacheConfig or RegionConfig. >> >> B) ... custom configuration elements, as well as any configuration object >> that we wish to be searchable within the configuration. >> >> C) ... custom configuration elements, as well as any configuration object >> appearing at the same level in the configuration hierarchy. That is, >> every >> getter of both CacheConfig and RegionConfig should return either a >> CacheElement, or a List. >> >> D) ... any object, excepting those in java.lang.*, that appears anywhere >> in >> the cluster configuration's hierarchy, including all inner classes. For >> example, ConnectorService.RegionMapping implements CacheElement. >> >> >> Each comes with its own potential pitfalls. >> Option (A) seems restrictive and sparse. >> Option (B) is subjective. >> Many classes do not have a `name' or `id' field, making option (D) >> difficult. >> I like option (C), although we have already moved beyond that >> specification in our current iteration, with >> ConnectorService.RegionMapping >> implementing CacheElement. >> >> Thoughts? >> >> Imagination is Change. >> ~Patrick Rhomberg >> >> > --089e0823bb34ac57c3056ab3f8c7--