Re: Solr Compile error

This is the full output? try verbose I had an issue with the same library in my case I was downloading from a local nexus mirror but the problem was with a bad checksum, I figured this out with the ant -verbose compile command. Disabling the checksum check for my local nexus and got it working j

Re: Solr Compile error

Is it possible you have a corporate firewall? And Java is not picking up automatic proxy? Regards, Alex. P.s. The repo error I think is normal. Some weird Maven thing in general. Personal: http://www.outerthoughts.com/ and @arafalov Solr resources and newsletter: http://www.solr-start.com/ and

Solr Compile error

Hi there when I "ant compile" solr 4.10.x, I got the following error: -- ivy-availability-check: [echo] Building solr-core... ivy-fail: ivy-fail: ivy-conf

Re: Disappearance of post.jar from the new tutorial

Could be nice to have the tutorial then as a runnable Solr core. With tutorial text, perhaps, showing up as an admin-extra or some such. Would that be of interest? Regards, Alex. Personal: http://www.outerthoughts.com/ and @arafalov Solr resources and newsletter: http://www.solr-start.com/ and

Re: Disappearance of post.jar from the new tutorial

You can still do the same thing with the solr-core JAR (note the CLASSPATH in the tutorial). I didn't want the new tutorial to rely on example/exampledocs directory, and to be able to run from the root directory. The embedded tutorial does need to be removed, or cloned. Removing it seems b

Re: Disappearance of post.jar from the new tutorial

But before you could take that jar to another machine or whatever. Plus, it run on Windows (I am reading SOLR-6435). Maybe it's opposite and this single class does not need to be in the solr-core's jar? Or the price of duplication is not that big. At least until we build a full-blown client. And -

Re: Disappearance of post.jar from the new tutorial

I removed reference to it as the same class is in solr-core's JAR. The idea is to hide the details behind bin/post and before end of year (before 5.0 release at least) to get that taken care of. Maybe post.jar can go away completely, but with bin/post the internal details won't matter. E

Disappearance of post.jar from the new tutorial

Hello, Anybody knows why the new online tutorial no longer mentions post.jar : http://lucene.apache.org/solr/quickstart.html Instead the command line offered is: java -Dauto -Drecursive org.apache.solr.util.SimplePostTool docs/ The post.jar is still there in both 4.10.2 and - so far - in 5. Co

Re: Standardized index metrics (Was: Constantly high disk read access (40-60M/s))

On 11/29/14 1:30 PM, Toke Eskildsen wrote: Michael Sokolov [msoko...@safaribooksonline.com] wrote: I wonder if there's any value in providing this metric (total index size - stored field size - term vector size) as part of the admin panel? Is it meaningful? It seems like there would be a lot o

Re: Constantly high disk read access (40-60M/s)

My read on docvalues is that "typical" use is to keep them in memory - at least when they are used, and if you are creating them, it makes sense to assume you are going to be using them? -Mike On 11/29/14 1:25 PM, Alexandre Rafalovitch wrote: There are also docValues files as well, right? And

Standardized index metrics (Was: Constantly high disk read access (40-60M/s))

Michael Sokolov [msoko...@safaribooksonline.com] wrote: > I wonder if there's any value in providing this metric (total index size > - stored field size - term vector size) as part of the admin panel? Is > it meaningful? It seems like there would be a lot of cases where it > could give a good rul

Re: Constantly high disk read access (40-60M/s)

There are also docValues files as well, right? And they have different memory requirements depending on how they are setup. (not 100% sure what I am trying to say here, though) Regards, Alex. Personal: http://www.outerthoughts.com/ and @arafalov Solr resources and newsletter: http://www.solr-st

Re: Constantly high disk read access (40-60M/s)

Of course testing is best, but you can also get an idea of the size of the non-storage part of your index by looking in the solr index folder and subtracting the size of the files containing the stored fields from the total size of the index. This depends of course on the internal storage stra

Re: Constantly high disk read access (40-60M/s)

bq: You should have memory to fit your whole database in disk cache and then some more. I have to disagree here if for no other reason than stored data, which is irrelevant for searching, may make up virtually none or virtually all of your on-disk space. Saying it all needs to fit in disk cache is

Re: Trying to get ALL scores from a previous search in a custom search component ("last-components")

Note that what I said doesn't apply if you use the underlying _index_ reading capabilities in Lucene. It's a bit more complicated than just fetching the doc, but it's all memory-resident thus fast. You need to unInvert the index though, and DocValues may be helpful here. Best, Erick On Fri, Nov 2

RE: Constantly high disk read access (40-60M/s)

Po-Yu Chuang [ratbert.chu...@gmail.com] wrote: > [...] Everything works fine now, but I noticed that the load > average of the server is high because there is constantly > heavy disk read access. Please point me some directions. > RAM: 18G > Solr home: 185G > disk read access constantly 40-60M/s

Re: Move a shard from one disk to another

Hi, I believe symlinks should work, you could try and see. Alternatively you could either set *coreRootDirectory* in solr.xml for where core discovery starts. Or keep the same root for core discovery, and tweak only the rele

Re: Constantly high disk read access (40-60M/s)

You should have memory to fit your whole database in disk cache and then some more. I prefer to have at least twice that to accommodate startup of new searchers while still serving from the "old". Less than that performance drops a lot. > Solr home: 185G If that is your database size then you nee

Re: SolrCloud replica always fully resync index from leader node

Hi Stephon, nothing obvious to me. But it is early in the morning for a saturday :D Did you comment out the old-style replication configuration since your first message ? Do you always see the same behavior ? Ludovic. - Jouve France. -- View this message in context: http://lucene.472066