I am seeing odd behavior where a query such as:
http://localhost:8983/solr/select/?q=moss&version=2.2&start=0&rows=10&indent=on&fq=docType%3AFancy+Doc
works until I add q.op=AND
http://localhost:8983/solr/select/?q=moss&q.op=AND&version=2.2&start=0&rows=10&indent=on&fq=docType%3AFancy+Doc
whic
BY the way, the fq parameter is being used to apply a facet value as a
refinement which is why it is not tokenized and is a string.
jayson.minard wrote:
>
> I am seeing odd behavior where a query such as:
>
> http://localhost:8983/solr/select/?q=moss&version=2.2&start=0&
Thinking about this, I could work around it by quoting the facet value so
that the AND isn't inserted between tokens in the fq parameter.
jayson.minard wrote:
>
> BY the way, the fq parameter is being used to apply a facet value as a
> refinement which is why it is not toke
Created issue:
https://issues.apache.org/jira/browse/SOLR-1155
Jim Murphy wrote:
>
> Any pointers to this newer more concurrent behavior in lucene? I can try
> an experiment where I downgrade the iwCommit lock to the iwAccess lock to
> allow updates to happen during commit.
>
> Would you
Can we move this to patch files within the JIRA issue please. Will make it
easier to review and help out a as a patch to current trunk.
--j
Jim Murphy wrote:
>
>
>
> Yonik Seeley-2 wrote:
>>
>> ...your code snippit elided and edited below ...
>>
>
>
>
> Don't take this code as correct
First cut of updated handler now in:
https://issues.apache.org/jira/browse/SOLR-1155
Needs review from those that know Lucene better, and double check for errors
in locking or other areas of the code. Thanks.
--j
jayson.minard wrote:
>
> Can we move this to patch files within the JIRA
Siddharth,
The settings you have in your solrconfig for ramBufferSizeMB and
maxBufferedDocs control how much memory may be used during indexing besides
any overhead with the documents being "in-flight" at a given moment
(deserialized into memory but not yet handed to lucene). There are
streaming
Indexing speed comes down to a lot of factors. The settings as talked about
above, VM settings, the size of the documents, how many are sent at a time,
how active you can keep the indexer (i.e. one thread sending documents lets
the indexer relax whereas N threads keeps pressure on the indexer), h
--j
Mike Klaas wrote:
>
> Hi Jayson,
>
> It is on my list of things to do. I've been having a very busy week
> and and am also working all weekend. I hope to get to it next week
> sometime, if no-one else has taken it.
>
> cheers,
> -mike
>
> On
