From java-user-return-64095-archive-asf-public=cust-asf.ponee.io@lucene.apache.org Fri Nov 9 16:37:56 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 D9E34180627 for ; Fri, 9 Nov 2018 16:37:55 +0100 (CET) Received: (qmail 51564 invoked by uid 500); 9 Nov 2018 15:37:54 -0000 Mailing-List: contact java-user-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: java-user@lucene.apache.org Delivered-To: mailing list java-user@lucene.apache.org Received: (qmail 51546 invoked by uid 99); 9 Nov 2018 15:37:53 -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; Fri, 09 Nov 2018 15:37:53 +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 7EB26C1BB1 for ; Fri, 9 Nov 2018 15:37:53 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -0.342 X-Spam-Level: X-Spam-Status: No, score=-0.342 tagged_above=-999 required=6.31 tests=[DKIMWL_WL_MED=-0.14, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd4-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 iMYbtvGqf7vO for ; Fri, 9 Nov 2018 15:37:51 +0000 (UTC) Received: from mail-lj1-f194.google.com (mail-lj1-f194.google.com [209.85.208.194]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTPS id 51A166245C for ; Fri, 9 Nov 2018 15:37:51 +0000 (UTC) Received: by mail-lj1-f194.google.com with SMTP id t9-v6so1951444ljh.6 for ; Fri, 09 Nov 2018 07:37:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=wwbQzhzfYOmOdugkwiN4ea8fMI6sTwL1V0LoPlfkzoI=; b=NLtYy252wjDqrCtAKL9Hjo4T1fjc7up/bywlxiCCIHVcjVtJRv7kuKOU2PMxVdb4Ol 6KbbE+wEwpQpm0aUNBdjDmEamjbymf0w4a1ekqNHmmA5tTKpqUSm/RKJ347f33ELbyUn vYOegQhUoaegcM5tA3VLlg6RZasdyGr448wK2jXe//b9PTKSdPmQ5VF2M4fp1chos8EN oxpf51DqkYfLcXtqNowkd0MDdO2FiXi7MMd/MfahS3GeuPZ5czohKaAQiKH+Mf4T7SF/ Gyujq06bbOnJgo6RoTnU4+YYejxKFdoe8Y0GVJGVWd5eWH3frcYRge2UUvA045CyYKgG e/WA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=wwbQzhzfYOmOdugkwiN4ea8fMI6sTwL1V0LoPlfkzoI=; b=YCA0N9DV6jmp8WqlKVJBH5IBr2eDIBCP8zwd160xItDdFAtF9CLDFfJaS7iJ4+I7zk Nn4JmggJfw6l/ZBtvjjKeTk8Fr6IYegq47gHYxQn+vz9TwYc2l/+YjRMCxvT+r3lRnrH +L3CIeWL3qgQuTfHmF1gIBwUqgqdHF41CkpuXOqFLn1W9iFmRhFXZQ/ZSPrfL0Ll6YqJ pwf2fQgdH3cuFXLESQEoQUA0hwXu4UMRgTwzAscvJ/UrB8Hkb+eYpmLW13m86bYGvcgC OolB9x9kJ1livNA+UpDycYY+nI7JWeJknJNh4icuhqeud/vVViYeRG9T05q9FQX6X/GH 50Ig== X-Gm-Message-State: AGRZ1gI0TBobRucW9wDuODeak3sh0r8LzdB0uA+0suiYeJETEOLtBx0D ZAvoAj/jEIzMkMkXheH5uzAejuWX/1UE2fF5vEVtKQ== X-Google-Smtp-Source: AJdET5e6UWOMgsgSZLhtJvZdExcy6auDInApos2qRXO9lQFZlSLEvssdKWpw7FA3jBVKKA61vsZMjC4sWiweJ1+a7BU= X-Received: by 2002:a2e:568b:: with SMTP id k11-v6mr6050592lje.105.1541777869307; Fri, 09 Nov 2018 07:37:49 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Erick Erickson Date: Fri, 9 Nov 2018 07:37:12 -0800 Message-ID: Subject: Re: SearcherManager not seeing changes in IndexWriteral and To: java-user Content-Type: text/plain; charset="UTF-8" If it's hard to do in a single thread, how about timestamping the events to insure that they happen in the expected order? That would verify the sequencing is happening as you expect and _still_ not see the expected docs... Assuming it does fail, do you think you could reduce it to a multi-threaded test case? Best, Erick On Fri, Nov 9, 2018 at 7:03 AM Boris Petrov wrote: > > Well, it's a bit involved to try it in a single thread as I've > oversimplified the example. But as far as I understand this should work, > right? So something else is wrong? Committing the writer and then > "maybeRefreshBlocking" should be enough to have the changes visible, yes? > > On 11/9/18 4:45 PM, Michael Sokolov wrote: > > That should work, I think, but if you are serializing these threads so > > that they cannot run concurrently, maybe try running both operations > > in a single thread, at least as a test. > > On Fri, Nov 9, 2018 at 9:16 AM Boris Petrov wrote: > >> If you mean the synchronization of the threads, it is not in the > >> example, but Thread 2 is *started* after Thread 1 finished executing the > >> code that I gave as an example. So there is happens-before between them. > >> If you mean synchronization on the Lucene level - isn't that what > >> "maybeRefreshBlocking" should do? > >> > >> On 11/9/18 3:29 PM, Michael Sokolov wrote: > >>> I'm not seeing anything there that would synchronize, or serialize, the > >>> read after the write and commit. Did you expect that for some reason? > >>> > >>> On Fri, Nov 9, 2018, 6:00 AM Boris Petrov >>> > >>>> Hi all, > >>>> > >>>> I'm using Lucene version 7.5.0. We have a test that does something like: > >>>> > >>>> Thread 1: > >>>> > >>>> Field idStringField = new StringField("id", id, > >>>> Field.Store.YES); > >>>> Field contentsField = new TextField("contents", reader); > >>>> Document document = new Document(); > >>>> document.add(idStringField); > >>>> document.add(contentsField); > >>>> > >>>> writer.updateDocument(new Term(ID_FIELD, id), document); > >>>> writer.flush(); // not sure this flush is needed? > >>>> writer.commit(); > >>>> > >>>> Thread 2: > >>>> > >>>> searchManager.maybeRefreshBlocking(); > >>>> IndexSearcher searcher = searchManager.acquire(); > >>>> try { > >>>> QueryParser parser = new QueryParser("contents", analyzer); > >>>> Query luceneQuery = parser.parse(queryText); > >>>> ScoreDoc[] hits = searcher.search(luceneQuery, > >>>> 50).scoreDocs; > >>>> } finally { > >>>> searchManager.release(searcher); > >>>> } > >>>> > >>>> Thread 1 happens before Thread 2. > >>>> > >>>> Sometimes, only sometimes, the commit from thread 1 is not *immediately* > >>>> visible in Thread 2. If I put a "Thread.sleep(1000)" it always works. > >>>> Without it, sometimes the search is empty. I'm not sure if I'm doing > >>>> something wrong or this is a bug? > >>>> > >>>> Thanks! > >>>> > >>>> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org > For additional commands, e-mail: java-user-help@lucene.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org For additional commands, e-mail: java-user-help@lucene.apache.org