Hey Alessandro,
thanks for your reply. A few minutes ago I found an issue in my code and now
everything is working as expected.
Sorry, for wasting for time :/
2015-11-10 16:25 GMT+01:00 Alessandro Benedetti
<[abenede...@apache.org](mailto:abenede...@apache.org)>:
\--
Mit fr
On Tue, Nov 10, 2015 at 7:47 AM, Rob Audenaerde
wrote:
> Ah yes, that is the way to go.
>
> It is a bit harder here, because we also use a per-user InMemoryIndex that
> is combined in a multi-reader, so it will be a bit more work, but I think
> it will be doable. Thanks for all the help.
>
> That
On Tue, Nov 10, 2015 at 6:19 AM, Jürgen Albert
wrote:
> In our case we had open index readers, that
> blocked the index from merging its segments and thus deleting the marked
> segments.
Small correction: merging is never blocked because of open NRT
readers. The merging happens and finishes eve
Hi Markus,
what is the logic behind your query parser?
How the query is expected to be rewritten ?
I've never seen that kind of rewritten query, but if you tell us what you
are expecting to rewrite, maybe would be easier to help!
Cheers
On 10 November 2015 at 14:31, Markus Boese wrote:
> Hi,
>
Hi,
I've written my own QueryParser and now i've a strange issue.
I'm parsing the following string : 'abcd 1'
Then this tokens are created: 'abcd' '1'
This is my query.toString() output : '+f:abcd f:abcd$ f:^abcd^4.0 +f:abcd[
, 1] f:^abcd[ , 1] +f:1'
Could anyone explain what lucene w
Ah yes, that is the way to go.
It is a bit harder here, because we also use a per-user InMemoryIndex that
is combined in a multi-reader, so it will be a bit more work, but I think
it will be doable. Thanks for all the help.
That said, I found it not-so-easy to debug this issue; are there methods
Hi Rob,
we use a SearcherManager to obtain a fresh Searcher for every Query.
From the Searcher we get the Reader. After the query you call
searcherManager.release(searcher). The SearcherManager takes care of the
rest.
Regards,
Jürgen.
Am 10.11.2015 um 13:27 schrieb Rob Audenaerde:
Hi Jürg
Hi Jürgen, Michael
Thanks! I seem to be able to reduce the index size by closing and
restarting our application. This reduces the index size from 22G tot 4G,
with is somewhat the expected size. The infoStream also gives me the
'removed unreferenced file (IFD 0 [2015-11-10T12:21:49.293Z; main]: ini
Hi Rob,
we had a similar problem. In our case we had open index readers, that
blocked the index from merging its segments and thus deleting the marked
segments.
Regards,
Jürgen.
Am 06.11.2015 um 08:59 schrieb Rob Audenaerde:
Hi will, others
Thanks for you reply,
As far as I understand it
