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 83BF5200C67 for ; Mon, 15 May 2017 12:51:13 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id 8242F160BC2; Mon, 15 May 2017 10:51:13 +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 C8D59160BC1 for ; Mon, 15 May 2017 12:51:12 +0200 (CEST) Received: (qmail 40076 invoked by uid 500); 15 May 2017 10:51:06 -0000 Mailing-List: contact dev-help@kafka.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@kafka.apache.org Delivered-To: mailing list dev@kafka.apache.org Received: (qmail 40056 invoked by uid 99); 15 May 2017 10:51:06 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 15 May 2017 10:51:06 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id 87398C030F for ; Mon, 15 May 2017 10:51:06 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -100.002 X-Spam-Level: X-Spam-Status: No, score=-100.002 tagged_above=-999 required=6.31 tests=[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 (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id wcf6MtreBftb for ; Mon, 15 May 2017 10:51:05 +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 8A1635FAF9 for ; Mon, 15 May 2017 10:51:05 +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 D4AA4E0D4E for ; Mon, 15 May 2017 10:51:04 +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 388A124309 for ; Mon, 15 May 2017 10:51:04 +0000 (UTC) Date: Mon, 15 May 2017 10:51:04 +0000 (UTC) From: "Lukas Gemela (JIRA)" To: dev@kafka.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Created] (KAFKA-5240) Make persistent checkpointedOffsets optionable MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 archived-at: Mon, 15 May 2017 10:51:13 -0000 Lukas Gemela created KAFKA-5240: ----------------------------------- Summary: Make persistent checkpointedOffsets optionable Key: KAFKA-5240 URL: https://issues.apache.org/jira/browse/KAFKA-5240 Project: Kafka Issue Type: Improvement Components: streams Affects Versions: 0.10.2.0 Reporter: Lukas Gemela By looking at the ProcessorStateManager class kafka streams library tries to persist current offset for each partition to the file. It has to use locking mechanism to be sure that there is no other thread/task running which is modifying the .checkpoint file. It does that even if you don't use persistent store in your topology (which is a bit confusing) From my understanding this is because you want to make active state restorations faster and not to seek from the beginning (ProcessorStateManager:217) We actually run everything in docker environment and we don't restart our microservices - we just run another docker container and delete the old one. We don't use persistent stores and we don't want to have our microservices to write anything to the filesystem. We always set aggressive [compact. delete] policy to get the kafka streams internal topics to have them compacted as much as possible and therefore we don't need a fast recovery either - we always have to replay whole topic no matter what. Would it be possible to make writing to the file system optionable? Thanks! L. -- This message was sent by Atlassian JIRA (v6.3.15#6346)