Return-Path: X-Original-To: apmail-geode-issues-archive@minotaur.apache.org Delivered-To: apmail-geode-issues-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 7DA20182C5 for ; Tue, 19 Jan 2016 19:20:44 +0000 (UTC) Received: (qmail 25001 invoked by uid 500); 19 Jan 2016 19:20:43 -0000 Delivered-To: apmail-geode-issues-archive@geode.apache.org Received: (qmail 24969 invoked by uid 500); 19 Jan 2016 19:20:43 -0000 Mailing-List: contact issues-help@geode.incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@geode.incubator.apache.org Delivered-To: mailing list issues@geode.incubator.apache.org Received: (qmail 24951 invoked by uid 99); 19 Jan 2016 19:20:43 -0000 Received: from Unknown (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 19 Jan 2016 19:20:43 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id 578A3180671 for ; Tue, 19 Jan 2016 19:20:43 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 0.426 X-Spam-Level: X-Spam-Status: No, score=0.426 tagged_above=-999 required=6.31 tests=[KAM_LAZY_DOMAIN_SECURITY=1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.554] autolearn=disabled Received: from mx1-eu-west.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id 3oaFgTaG3LyZ for ; Tue, 19 Jan 2016 19:20:42 +0000 (UTC) Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx1-eu-west.apache.org (ASF Mail Server at mx1-eu-west.apache.org) with SMTP id 093ED23016 for ; Tue, 19 Jan 2016 19:20:40 +0000 (UTC) Received: (qmail 24804 invoked by uid 99); 19 Jan 2016 19:20:40 -0000 Received: from arcas.apache.org (HELO arcas) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 19 Jan 2016 19:20:40 +0000 Received: from arcas.apache.org (localhost [127.0.0.1]) by arcas (Postfix) with ESMTP id 02C9F2C1F62 for ; Tue, 19 Jan 2016 19:20:40 +0000 (UTC) Date: Tue, 19 Jan 2016 19:20:40 +0000 (UTC) From: "Dan Smith (JIRA)" To: issues@geode.incubator.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (GEODE-10) HDFS Integration MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/GEODE-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15107240#comment-15107240 ] Dan Smith commented on GEODE-10: -------------------------------- The HDFS feature was disabled and removed from the public API with GEODE-429, because it was still unstable. It doesn't look to me like a feature branch was ever created to restore the public API for HDFS and fix the stability issues. I think the next step on this issue is probably to create that branch, revert the commits listed on GEODE-409 and fix the stability issues. Otherwise, we should rip out the HDFS code if we are not planning on getting this working with the current design. > HDFS Integration > ---------------- > > Key: GEODE-10 > URL: https://issues.apache.org/jira/browse/GEODE-10 > Project: Geode > Issue Type: New Feature > Components: hdfs > Reporter: Dan Smith > Assignee: Ashvin > Fix For: 1.0.0-incubating.M1 > > Attachments: GEODE-HDFSPersistence-Draft-060715-2109-21516.pdf > > > Ability to persist data on HDFS had been under development for GemFire. It was part of the latest code drop, GEODE-8. As part of this feature we are proposing some changes to the HdfsStore management API (see attached doc for details). > # The current API has nested configuration for compaction and async queue. This nested structure forces user to execute multiple steps to manage a store. It also does not seem to be consistent with other management APIs > # Some member names in current API are confusing > HDFS Integration: Geode as a transactional layer that microbatches data out to Hadoop. This capability makes Geode a NoSQL store that can sit on top of Hadoop and parallelize the process of moving data from the in memory tier into Hadoop, making it very useful for capturing and processing fast data while making it available for Hadoop jobs relatively quickly. The key requirements being met here are > # Ingest data into HDFS parallely > # Cache bloom filters and allow fast lookups of individual elements > # Have programmable policies for deciding what stays in memory > # Roll files in HDFS > # Index data that is in memory > # Have expiration policies that allows the transactional set to decay out older data > # Solution needs to support replicated and partitioned regions -- This message was sent by Atlassian JIRA (v6.3.4#6332)