Well, while debugging I put a bunch of println's which showed the
expected order. And, besides, I've written the code, I know that writing
to the index happens way before searching in it - the test makes sure of
that.
If you think there indeed might be some problem, I'll try to reproduce
it in a small example. But I will try only the obvious (which perhaps
you've tried a million times and have tests for) - I'll have one thread
write to the index, another (which starts after the first) search in it
and I'll create a bash script that runs the program until it fails (what
I currently do with our test). I'll do this beginning of next week.
Thank you for the support!
On 11/9/18 5:37 PM, Erick Erickson wrote:
> 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 <boris_pet...@live.com> 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 <boris_pet...@live.com> 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 <boris_pet...@live.com wrote:
>>>>>
>>>>>> 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-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: java-user-h...@lucene.apache.org
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
> For additional commands, e-mail: java-user-h...@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-user-h...@lucene.apache.org
