t after that. Sorry
> all for the confusion! Thanks for the support!
>
> From: Erick Erickson
> Sent: Friday, November 9, 2018 6:16 PM
> To: java-user
> Subject: Re: SearcherManager not seeing changes in IndexWriteral and
>
> You might
PM
To: java-user
Subject: Re: SearcherManager not seeing changes in IndexWriteral and
You might be able to do this with a couple of threads in a single
program, but certainly up to you.
Best,
Erick
On Fri, Nov 9, 2018 at 7:47 AM Boris Petrov wrote:
>
> Well, while debugging I put a bu
You might be able to do this with a couple of threads in a single
program, but certainly up to you.
Best,
Erick
On Fri, Nov 9, 2018 at 7:47 AM Boris Petrov wrote:
>
> Well, while debugging I put a bunch of println's which showed the
> expected order. And, besides, I've written the code, I know th
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 s
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-thread
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, Mi
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 th
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"
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:
>
>
