From dev-return-321675-archive-asf-public=cust-asf.ponee.io@lucene.apache.org Wed May 9 16:16:09 2018 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx-eu-01.ponee.io (Postfix) with SMTP id 0EAEC180649 for ; Wed, 9 May 2018 16:16:08 +0200 (CEST) Received: (qmail 71545 invoked by uid 500); 9 May 2018 14:16:03 -0000 Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@lucene.apache.org Delivered-To: mailing list dev@lucene.apache.org Received: (qmail 71535 invoked by uid 99); 9 May 2018 14:16:02 -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; Wed, 09 May 2018 14:16:02 +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 6F7F8C62D3 for ; Wed, 9 May 2018 14:16:02 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -110.3 X-Spam-Level: X-Spam-Status: No, score=-110.3 tagged_above=-999 required=6.31 tests=[ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=disabled Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id 8z2xyfEoGB6D for ; Wed, 9 May 2018 14:16:01 +0000 (UTC) Received: from mailrelay1-us-west.apache.org (mailrelay1-us-west.apache.org [209.188.14.139]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTP id 430775F23D for ; Wed, 9 May 2018 14:16:01 +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 6DECDE0EEA for ; Wed, 9 May 2018 14:16:00 +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 042D72129F for ; Wed, 9 May 2018 14:16:00 +0000 (UTC) Date: Wed, 9 May 2018 14:16:00 +0000 (UTC) From: "Peter (JIRA)" To: dev@lucene.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Created] (SOLR-12334) Improved detection of recreated lock files MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 Peter created SOLR-12334: ---------------------------- Summary: Improved detection of recreated lock files Key: SOLR-12334 URL: https://issues.apache.org/jira/browse/SOLR-12334 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Reporter: Peter Just wanted to let you know, in accordance to the Contribution Guidelines, that I created a pull request on GitHub ([https://github.com/apache/lucene-solr/pull/374).] h1. Commit Message Improve detection of recreated lock files I've been running into issues with the detection of deleted and then recreated files when using GlusterFS. Since, on most platforms, there are more reliable ways to detect recreated files, I decided improved the detection of such files. Background: As part of LUCENE-6508 [3] detection of recreated files was added. In such a case, another instance may have obtained lock on the newly created file. This isn't something that should happen on a properly configured Solr instance but there is a good chance for this happening when an index is shared by multiple instances that use a different locking mechanism. Implementation: On platform that support it, fileKey() [1] is now used. On Unix-like systems this key consists of the device ID and and inode. For locks that keep the lock file open, this should ensure we detect recreation since no two files can have the same device ID and inode even if the last hard link has been removed already. Other locks, that don't keep the file open, should still detect recreation at a low error rate. Platforms without fileKey() support keep using the creation timestamp or modification timestamp (subject to availability) [2]. [1]: https://docs.oracle.com/javase/8/docs/api/java/nio/file/attribute/BasicFileAttributes.html#fileKey-- [2]: https://docs.oracle.com/javase/8/docs/api/java/nio/file/attribute/BasicFileAttributes.html#creationTime-- [3]: https://issues.apache.org/jira/browse/LUCENE-6508 -- This message was sent by Atlassian JIRA (v7.6.3#76005) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org For additional commands, e-mail: dev-help@lucene.apache.org