Re: DIH wiht several Cores

Unfortunately, what you are asking for is not possible. The DIH needs to be configured separately for each core. I have a similar situation with my Solr application. I am solving it by creating a custom index feeder that is aware of all of the cores and which documents to send to which cores. --

How does DIH multithreading work?

I understand that the thread count is specified on root entities only. Does it spawn multiple threads per root entity? Or multiple threads per descendant entity? Can someone give an example of how you would make a database query in an entity with 4 threads that would select 1 row per thread? Than

Re: How does DIH multithreading work?

Anyone know how it works? -- View this message in context: http://lucene.472066.n3.nabble.com/How-does-DIH-multithreading-work-tp1776111p1784419.html Sent from the Solr - User mailing list archive at Nabble.com.

Core/shard preference

I have a small core performing deltas quickly (core00), and a large core performing deltas slowly (core01), both on the same set of documents. The delta core is cleaned nightly. As you can imagine, at times there are two versions of a document, one in each core. When I execute a query that matches

Re: Core/shard preference

s" because the searches >> are not compared all at once. Only the page of results fetched is >> compared, so there's no way to suppress a result in the second page if >> it was already found in the first. >> >> On Mon, Oct 19, 2009 at 3:30 PM, markwaddle wrot

RE: Solr under tomcat - UTF-8 issue

I was originally using POST for the same reason, however I discovered that Tomcat could easily be configured to accept any length URI. All it requires is specifying the maxHttpHeaderSize attribute in your default Connector in server.xml. I set my value to 1MB, which is certainly excessive, but it

Delete, commit, optimize doesn't reduce index file size

I have an index that used to have ~38M docs at 17.2GB. I deleted all but 13K docs using a delete by query, commit and then optimize. A "*:*" query now returns 13K docs. The problem is that the files on disk are still 17.1GB in size. I expected the optimize to shrink the files. Is there a way I can

Re: Delete, commit, optimize doesn't reduce index file size

Yonik Seeley-2 wrote: > > On Tue, Dec 29, 2009 at 1:23 PM, markwaddle wrote: >> I have an index that used to have ~38M docs at 17.2GB. I deleted all but >> 13K >> docs using a delete by query, commit and then optimize. A "*:*" query now >> returns 13

Re: Delete, commit, optimize doesn't reduce index file size

Yonik Seeley-2 wrote: > > If you make further changes to the index and do a commit, you should > see the space go down. > It worked. I added a bogus document using /update and then performed a commit and now the files are down to 6MB. http://.../core00/update?stream.body=%3Cadd%3E%3Cdoc%3E%3

Unexpected boolean query behavior

Here is my query: (virt* AND "machine fingerprinting") OR (virt* AND encryption) OR (virt* AND anonymous) OR (virt* AND analytic*) AND owned:true It can be broken down to: (A) OR (B) OR (C) OR (D) AND E A, B, C and D are themselves AND boolean clauses. The E clause at the end is not behaving th

Re: Unexpected boolean query behavior

t; -- > Sematext -- http://sematext.com/ -- Solr - Lucene - Nutch > > > > - Original Message >> From: markwaddle >> To: solr-user@lucene.apache.org >> Sent: Thu, January 14, 2010 2:39:21 PM >> Subject: Unexpected boolean query behavior >> >> >> Here i

Re: Unexpected boolean query behavior

That explains my exact problem, thank you! May I ask how you found that wiki posting? Otis Gospodnetic wrote: > > HI Mark, > > Does this help? > http://wiki.apache.org/lucene-java/BooleanQuerySyntax > > Otis > -- > Sematext -- http://sematext.com/ -- Solr - Lucene - Nutch > -- View this mes