It boils down to:
1. client sends some work and a notification channel to a single worker,
then waits.
2. worker processes the work
3. worker sends the result to the client using the notification channel
I do not see any problem with this, even with unbuffered channels.
Use this option when rebuilding indexes from scratch. In my small case
(~17000 json documents), it reduces indexing from 520s to 250s.
I did not add any test, short of forced indexing termination it only
has performance effects, which are hard to test. And unknown options are
currently ignored.
Issue #240
I stumbled onto that while trying to understand how analyzers are
resolved. The new code looks simpler to me and removes useless calls to
DocumentMapping.defaultAnalyzerName() when an analyzer is set at
FieldMapping level.
The slight change to TestStoredFieldPreserved avoids a stacktrace when
the test fails.
This is not the final word on this but it would have helped me a lot
starting with bleve. I left out details about value processing and
custom parsers. I also ignored that named FieldMapping can directly
resolve value fields without having a parent SubDocumentMapping because
it did not appear in any example I read.
Let's consider this as a starting point for documentation improvements.
benchmark old ns/op new ns/op delta
BenchmarkBatch-4 16950972 16377194 -3.38%
benchmark old allocs new allocs delta
BenchmarkBatch-4 136164 136161 -0.00%
benchmark old bytes new bytes delta
BenchmarkBatch-4 7168872 7109691 -0.83%
benchmark old ns/op new ns/op delta
BenchmarkBatch-4 20738739 17047158 -17.80%
benchmark old allocs new allocs delta
BenchmarkBatch-4 136423 136160 -0.19%
benchmark old bytes new bytes delta
BenchmarkBatch-4 20277781 7168772 -64.65%
benchmark old ns/op new ns/op delta
BenchmarkAnalysis-4 1599218 1540991 -3.64%
benchmark old allocs new allocs delta
BenchmarkAnalysis-4 5353 5318 -0.65%
benchmark old bytes new bytes delta
BenchmarkAnalysis-4 370495 362983 -2.03%